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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds non-obvious behavior beyond them: the empty_response label semantics and the warning that empty results are 'silence, not a measurement' that must not be reported as 'no problems found'. It also flags that untrusted fields must be treated as data, not instructions, which is meaningful prompt-injection guidance annotations cannot convey.

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?

Front-loads what the tool does, then routing exclusions, then interpretation caveats, in a tight sequence of sentences. Each sentence adds distinct value; none restates structured fields.

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?

With no output schema, the description usefully explains the return behavior via the empty_response label and interpretation rule, and it handles sibling disambiguation thoroughly. The remaining gap is the site_url format, which is undocumented in both the schema and the description.

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 coverage is 0% for the single required site_url parameter, so the description carries the full burden. It implies scoping to 'one site' but never states the expected format (domain vs. full URL, scheme, trailing slash), leaving an agent to guess a value it must supply correctly.

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?

States a specific verb (List) and resource (URL block requests Bing holds for one site), and explicitly enumerates the two subtypes covered: full removals and cache-only removals. It distinguishes itself from bing_page_preview_blocks and bing_deep_link_blocks by name, so an agent can route without opening schemas.

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?

Gives an explicit positive trigger ('when the user asks which URLs are hidden from Bing or had their cached copy removed') and two explicit exclusions, each with the named alternative tool to call instead. 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.

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

Annotations already establish readOnly/idempotent/non-destructive, but the description adds value beyond them: it explains that http_status_reported is false when Bing's HttpStatus is 0, and that an empty result carries an empty_response label meaning silence rather than 'no problems found.' It also declares untrusted fields must be treated as data, a real injection-defense instruction.

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?

Routing constraint is front-loaded and most sentences earn their place, but the trailing 'See bing_url_info' restates what the earlier 'call bing_url_info' already covered, and the density of caveats makes it longer than strictly needed.

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?

With no output schema, the description does well to explain row contents and the empty_response signal, and it handles sibling routing fully. The gap is input-side: for a four-parameter tool with zero schema documentation, an agent still cannot tell what site_url or filter_properties should contain.

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%, so the description carries the full burden for url, site_url, page, and filter_properties. It only implies that 'one URL' is required and says nothing about site_url, pagination via page, or the nested filter_properties object, leaving three of four parameters unexplained.

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?

States a specific verb and resource: 'List the child URLs under one URL with the crawl record Bing holds for each.' It names the sibling it is not (bing_url_info for the parent, bing_children_url_traffic_info for traffic), so an agent can disambiguate 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?

Gives an explicit trigger ('Use when the user asks what Bing knows about the paths under a URL') plus two explicit exclusions with named alternatives for each case. Nothing about routing 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.

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description goes further and discloses the empty-response semantics ('empty_response label: that is silence, not a measurement') and an untrusted-data handling rule. These are genuine behavioral facts not derivable from structured fields. It stops short of describing pagination behavior despite a page parameter, so it is not flawless.

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 tight sentences, each doing load-bearing work: purpose, trigger, exclusion-with-alternative, and two behavioral caveats. The primary purpose is front-loaded, and there is no filler or repetition.

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?

With no output schema and no annotation coverage of edge cases, the description compensates by explaining the empty_response label and the untrusted-field rule, which are exactly the gaps an agent would otherwise mishandle. The only residual gap is the undocumented param semantics (url vs site_url, page), so it is strong but not fully complete.

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% across three parameters, so the description carries the full burden, and it does not explain the crucial distinction between 'url' and 'site_url' or what 'page' does. The phrase 'child URLs under one URL' hints at the url parameter but leaves site_url ambiguous. It adds little meaning beyond what a bare schema already shows.

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?

States a specific verb and resource ('List Bing search-traffic records for the child URLs under one URL') and immediately delimits against the nearest sibling by naming bing_children_url_info as the crawl-status tool. An agent can distinguish it from bing_url_traffic_info and bing_children_url_info 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?

Gives an explicit positive trigger ('Use when the user asks which paths under a URL get Bing traffic') and an explicit exclusion with the correct alternative ('Do not use this for the children's crawl status; call bing_children_url_info'). Both when-to-use and when-not-to-use are covered, leaving nothing to inference.

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

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.

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered, yet the description adds non-obvious semantics: the empty_response label meaning 'silence, not a measurement' and the prohibition on reporting it as 'no problems found'. It also warns to treat untrusted-marked fields as data, not instructions — behavior an agent could not infer elsewhere.

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?

Front-loads the purpose, then usage, then the failure-mode caveat, then the safety instruction — a logical order with no filler. It is denser and slightly longer than minimal, but every sentence carries distinct information.

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?

With no output schema, the description steps in to explain return-value semantics (the empty_response label) and the untrusted-data handling, which is exactly what an agent needs to interpret results correctly. Nothing material is missing for a single-parameter read 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 coverage is 0%, so the description carries the burden, but it only implies a single-site scope via 'for one site today' rather than describing site_url's expected format or constraints. It adds marginal meaning over the bare string parameter without fully compensating for the coverage gap.

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?

States a precise verb ('Read'), an exact resource ('how much content submission Bing still allows'), and scope ('for one site today'). It explicitly names the sibling it is not ('Do not use this for ordinary URL-submission quota; call bing_submission_quota'), so an agent can distinguish it from bing_submission_quota without opening either 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?

Explicit trigger ('Use when the user asks whether a page body can still be submitted') and explicit exclusion routing to an alternative ('Do not use this for ordinary URL-submission quota; call bing_submission_quota'). Nothing about when to select this tool 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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: the bitmask semantics that let one URL fall into several categories, the http_4xx/http_404/http_403 subset trap, the absence of any noindex flag, and the empty_response-is-silence warning. It omits only pagination or result-size limits, a minor gap.

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?

Front-loaded with purpose, then the alternative and the return contract before the caveats. The long enumeration of issue categories and HTTP-code caveats is dense but each clause prevents a real reporting error, so it largely earns its space even if it runs long.

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?

No output schema exists, so the description correctly explains the return object keys, the category labels, and the untrusted-field handling. It also covers the empty-result edge case, which an agent could otherwise misreport as 'no problems found'.

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?

One parameter with 0% schema description coverage, so the description carries the burden. 'For one site' does convey single-site scoping, but it never states the expected site_url format (domain vs full URL, protocol, subdomain handling). Adequate, not complete.

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?

States a specific verb and resource ('List crawl issues Bing reports for one site') plus the exact shape of what comes back ('count per category and HTTP code'). It names the sibling it is not (bing_crawl_stats), so an agent can route between them without opening a 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?

Gives an explicit trigger ('Use when the user asks which URLs Bing failed to crawl and why'), an explicit exclusion ('Do not use this for site-wide crawl totals') and the alternative to call instead (bing_crawl_stats). 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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds two behaviors the annotations cannot convey: the empty_response label means silence rather than a clean result and must not be reported as 'no problems found', and untrusted-marked fields must be treated as data, not instructions. Both are non-obvious, high-consequence traits for an agent.

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, purpose front-loaded, then trigger, then exclusion, then edge-case warnings. No filler and nothing repeated from the structured fields.

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?

With no output schema, the description carries the return burden and handles the critical empty-result case, so an agent will not misreport an absence of data as a clean bill of health. The only gap is the site_url format, which neither schema nor description resolves.

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 site_url parameter, and the description only says 'one site' without giving the expected format (scheme, host, path, or property identifier). The schema already supplies name and type, so the description adds a little scoping but not the syntax needed to call it confidently.

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?

States a specific verb and resource ('Read the crawl settings Bing has for one site') and enumerates the content ('crawl rate and crawl boost'). It explicitly distinguishes itself from bing_crawl_stats, so an agent can separate it from the 60+ sibling tools without opening a 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?

Gives an explicit trigger ('when the user asks how fast Bing is allowed to crawl the site') plus a negative case with the named alternative ('Do not use this for crawl totals or errors; call bing_crawl_stats'). This is exactly the when/when-not/alternative pattern.

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

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

Goes well beyond the annotations (which already cover readOnly/idempotent/non-destructive): it documents the empty_response label semantics, warns that an empty result is 'silence, not a measurement' and must not be reported as 'no problems found', and flags untrusted fields as data rather than instructions. These are non-obvious behavioral traits an agent could not infer from structured fields.

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 tight sentences with no filler: purpose first, then usage, then the sibling exclusion, then result-interpretation caveats. Every sentence carries actionable information and the purpose leads.

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?

With no output schema, the description compensates by explaining the shape of results (crawl totals, errors, inbound links) and the empty_response label semantics. Combined with the injection warning, an agent has everything needed to call and correctly interpret this read 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 site_url parameter, and the description only implies single-site scoping ('for one site') without specifying the expected format (full URL vs. domain vs. property identifier). It conveys the operational unit but not the value syntax the schema leaves undocumented.

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?

States a specific verb ('Read') and resource ('Bing crawl totals') with scope ('for one site') and enumerates the content ('crawl errors and inbound links'). It also explicitly names the sibling bing_crawl_issues as the wrong tool for a related task, so an agent can distinguish it without opening the 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?

Gives an explicit triggering condition ('use when the user asks how much Bing crawled or whether crawl volume changed') and an explicit exclusion with a redirect ('Do not use this for the individual broken URLs; call bing_crawl_issues'). Both the when and the when-not are covered.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower, yet the description adds meaningful context beyond them: the empty_response label semantics ('silence, not a measurement') and the untrusted-field handling rule. These are genuinely useful behavioral disclosures that aren't captured by the annotations.

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?

Front-loaded with the core action, then usage, then exclusions, then the two critical caveats about empty results and untrusted data. Every sentence earns its place despite being multi-sentence.

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?

For a simple read-only list tool with one required parameter and no output schema, the description covers purpose, routing, the misleading-empty-result trap, and prompt-injection safety. An agent has everything needed to call and interpret it correctly.

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?

The single site_url parameter has 0% schema description coverage, so the description carries the burden. It implies scoping to 'one site' but never clarifies the expected format (full URL vs host) or any constraints, adding only marginal meaning over the bare schema.

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?

States a specific verb and resource ('List the deep-link blocks Bing has for one site') and explicitly names the sibling it must not be confused with (bing_page_preview_blocks). An agent can distinguish it from bing_blocked_urls and bing_page_preview_blocks 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?

Provides an explicit when-to-use trigger ('user asks which sitelinks or deep links are suppressed') and an explicit when-not with a redirect to the alternative tool. 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.

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: the empty_response label semantics, the warning that empty results are silence rather than a clean bill of health, and the handling of untrusted fields. These are non-obvious operational facts an agent must know before reporting results.

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?

Front-loaded purpose, then usage, then failure-mode and safety caveats. Every sentence adds distinct value with no repetition of the schema or annotations.

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?

With no output schema, the description supplies the missing output semantics: the empty_response label and how to interpret it, plus the untrusted-data rule. Combined with the annotations, an agent has everything needed to call and interpret this tool correctly.

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 both parameters, so the description carries the full burden. 'One URL it has crawled' loosely implies the meaning of url, but site_url is never mentioned and neither parameter's expected format or relationship is explained. This is a real gap for a required two-parameter tool.

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?

States a specific verb and resource ('Read Bing's fetch detail for one URL it has crawled') with explicit singular scope. The description immediately distinguishes it from the sibling bing_fetched_urls, so an agent can select correctly without opening either 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?

Gives an explicit trigger ('when the user asks what happened the last time Bing fetched a specific URL') and an explicit exclusion with a named alternative ('Do not use this for the list of recent fetches; call bing_fetched_urls'). Nothing about selection 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.

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world read. The description adds genuinely useful context beyond that: an empty result carries an empty_response label and means silence rather than 'no problems found', plus a directive to treat untrusted fields as data not instructions. That is real behavioral value. However, it says nothing about pagination, row limits, or the shape of returned rows, so it does not fully clear the higher bar annotations set.

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?

Front-loads the core purpose, then layers routing exclusions, then return-value semantics and the safety directive. No sentence is redundant; every clause earns its place.

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?

For a single-parameter read tool, the description covers the safety profile the annotations already imply, plus the two things an agent could otherwise get wrong: interpreting an empty result and mishandling untrusted return fields. With no output schema, it also pre-empts a misread of empty results. Nothing essential is missing.

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?

One required parameter, site_url, with 0% schema description coverage, so the description must compensate. It implies single-site scoping ('on one site') but gives no expected format (full URL vs. domain vs. property) or normalization rules for site_url. Baseline 3 is appropriate – it adds marginal meaning without fully compensating for the coverage gap.

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?

States a specific verb, resource, and scope ('List URLs Bing recently fetched on one site'), and immediately names the two siblings it is not (bing_fetched_url_details, bing_crawl_issues). An agent can distinguish it from the large sibling set 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?

Gives an explicit positive trigger ('Use when the user asks what Bing crawled lately') followed by two explicit exclusions, each routing to a named alternative tool. This is textbook when/when-not guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds behavior annotations cannot: empty-response semantics ('silence, not a measurement', must not be reported as 'no problems found') and a prompt-injection handling rule for untrusted fields. This is substantive context beyond the structured hints.

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?

Purpose is front-loaded and every sentence carries a distinct job: purpose, trigger, exclusion/alternative, empty-response interpretation, and data-safety rule. 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?

For a one-param listing tool with no output schema, the description covers what to expect on an empty result and how to treat returned data, which is the main missing piece from structured fields. Only the site_url format is left unaddressed.

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?

Single required parameter site_url with 0% schema description coverage. The description implies 'one site' but never specifies the expected format (protocol, trailing slash, domain vs. full URL), so it does not compensate for the coverage gap.

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?

States a specific verb and resource: 'List country and region targeting rules Bing has for one site.' It also explicitly distinguishes itself from the sibling bing_query_parameters, so an agent can route correctly 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?

Gives explicit trigger ('Use when the user asks how a URL is geotargeted') and an explicit exclusion with the named alternative ('Do not use this for query parameters; call bing_query_parameters'). No inference required.

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

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses that it sends nothing to Bing or IndexNow, consumes no quota, records no plan, and stores the key nowhere — directing the operator to save and publish it. These are exactly the non-obvious behavioral facts an agent needs for a planning tool, and they are consistent with the annotations.

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?

Purpose, scope, alternatives, and the side-effect profile are front-loaded across four tight sentences with no filler. It is slightly longer than needed — the quota/plan sentence and the closing 'key is not stored' sentence overlap thematically — but every sentence carries real information.

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?

With no output schema, the description still tells the agent what it produces (key material, key-file URL, file bytes, live-file status), what it does not do (no submission, no quota, no plan), and the required follow-up (operator must save and publish the key). This is complete for a read-only planning tool with four undocumented parameters.

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%, so the description carries the full burden, yet it never names the parameters. It conceptually implies the meaning of 'key' (generate or supply an existing one), 'host', 'key_location', and 'check_key_file' (report whether the file is served), but the agent must still guess the exact semantics, formats, and whether key_location is an input or output.

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 states a specific verb and resource — working out IndexNow key material for a host — and enumerates the concrete outputs (a key, the key-file URL, the required file bytes, whether the file is already served). It explicitly contrasts itself with the submission siblings, so an agent can distinguish it 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 'use when' condition (the user needs an IndexNow key or wants to know if the key file is live) and an explicit 'do not use this to submit URLs' exclusion paired with the correct alternatives (bing_indexnow_submit for direct writes, bing_plan_indexnow_submit when a human applies the plan). 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.

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value beyond them: the tool is not site-scoped, empty results carry an empty_response label that must not be read as 'no problems found', and untrusted fields must be treated as data. What is missing is any note on auth/permission requirements or rate limits, so a 4 rather than a 5.

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?

The core purpose is front-loaded in the first sentence, followed by usage routing and then critical reporting caveats. Every sentence carries distinct operational information with no redundancy.

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?

No output schema exists, so the description takes on return-value responsibility and does so by explaining the empty_response label and its interpretation. It also warns about untrusted fields, covering the safety dimension an agent needs before acting on results.

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?

With 0% schema description coverage, the description must carry parameter meaning, and it only maps them loosely ('one query, country and language, totalled over a date range') without format guidance such as country/language code conventions or date format. It clarifies the aggregation semantics but leaves the actual input formats undocumented.

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?

States a specific verb and resource ('Read Bing keyword impressions') with explicit scope (one query/country/language, totalled over a date range). It also disambiguates from siblings by naming bing_keyword_stats and bing_traffic_query as the wrong tools for adjacent needs.

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?

Provides explicit when-to-use ('user asks how much search demand a keyword had in a given period'), when-not-to-use, and named alternatives for each excluded case. Two distinct exclusion scenarios are routed to the correct sibling tools.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond that: the empty_response label semantics ('silence, not a measurement') and the untrusted-field handling directive. These are behavioral traits the annotations cannot express.

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?

Front-loaded with the core action, then routing guidance, then edge-case handling. Dense but every sentence earns its place. The empty_response explanation could be tighter but it is important.

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?

Covers purpose, alternative routing, and empty-result semantics without an output schema. The main gap is country/language format expectations given 0% schema coverage, but otherwise the description is complete for correct invocation.

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%, so the schema carries only names and types. The description says 'one keyword in a country and language' which gives positional context but no format details for country or language codes. Baseline 3 applies given the description adds only marginal meaning over the bare schema.

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?

States a specific verb (Read) and resource (Bing's historical statistics for one keyword) with explicit scope (one country and language, not tied to a site). This clearly distinguishes it from bing_keyword and bing_related_keywords.

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?

Explicitly names when to use (user asks how a keyword trended over time) and when not to use, routing to bing_related_keywords for related queries and bing_keyword for summed impressions. This is a textbook when/when-not/alternatives pattern.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds behavioral context those annotations cannot express: pagination granularity, the empty_response label and the explicit rule that silence must not be reported as 'no problems found', and a prompt-injection guard for untrusted fields. These are high-value, non-obvious traits.

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 doing distinct work: purpose, trigger, exclusion/alternative, then failure-mode and safety semantics. The scoping and alternative routing are front-loaded before the cautionary details.

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?

With no output schema, the description correctly compensates by explaining the empty-response contract and the untrusted-field policy. The only real gap is the unaddressed site_url convention and pagination bounds, minor relative to everything else it covers.

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%, so the description must carry full parameter meaning, and it largely does not. 'One page of results at a time' hints that 'page' drives paging, but there is no page numbering scheme, default, or maximum, and nothing describes the expected format of site_url (full URL vs. domain, protocol requirements).

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?

States a specific verb and resource ('Read inbound-link counts Bing reports for one site') plus the unit of retrieval ('one page of results at a time'). It explicitly distinguishes itself from the nearest sibling by naming bing_url_links and the different data that tool returns.

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?

Gives an explicit trigger ('Use when the user asks how many links Bing sees pointing at the site') and an explicit exclusion with a redirect ('Do not use this for the linking URLs themselves; call bing_url_links'). Nothing about tool selection 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.

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, but the description adds genuinely non-obvious behavior: an empty result carries an empty_response label and must not be read as 'no problems found', and untrusted fields must be treated as data not instructions. Both are safety-critical traits absent from the annotations.

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?

Purpose is front-loaded, then usage, then the sibling exclusion, then the reporting caveat and the untrusted-data rule. Every sentence adds a distinct, actionable constraint with no repetition or 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?

With no output schema, the description still conveys the meaningful return semantics (empty_response labeling, untrusted fields). For a single-parameter read tool with full annotation coverage, this is complete enough to call and interpret correctly.

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%, so the description carries the burden for site_url. It says 'for one site' but never clarifies the expected format (bare domain vs. full URL vs. verified site identifier), which is the one real ambiguity for this parameter. Minimum viable rather than compensating for the coverage gap.

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?

States a specific verb and resource ('List the page-preview blocks Bing has for one site') and immediately scopes it to a single site. It explicitly distinguishes itself from the closest lexical sibling, bing_blocked_urls, so an agent can route correctly without opening either 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?

Gives an explicit when ('the user asks which snippets or previews are suppressed'), an explicit when-not ('URLs blocked from the index'), and names the alternative tool to call instead. 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.

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), the description discloses that no change is sent to Bing, that this only records intent pending human review, that it may consume quota, that the agent must not tell the user the change was applied, and what to return (plan id plus CLI apply command). That is exactly the extra behavioral context 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.

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

Six short sentences, front-loaded with purpose, then mode semantics, then routing exclusions, then side-effect/return warnings. Every sentence carries unique information; nothing is repeated from the schema or annotations.

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?

For a plan-recording tool with no output schema and an undeclared nested object, the description supplies the missing workflow context: it is a two-step plan/apply flow with human review, and the agent should return the plan id plus apply command. Nothing needed for correct invocation or follow-up is absent.

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 coverage is 0% and blocked_url is an unstructured nested object, so the description carries the burden for parameters. It does explain the RequestType values (1=FullRemoval, 0=CacheOnly), which maps to the nested object's key fields, but it never explains site_url or the accepted shape/keys of blocked_url. Partial compensation only.

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 states a specific verb and resource ('Record a plan to block one URL in Bing') and immediately distinguishes the two modes via RequestType 1 (FullRemoval) vs RequestType 0 (CacheOnly). An agent can distinguish this from siblings such as bing_blocked_urls and bing_plan_remove_blocked_url 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 names the triggering condition ('when the user asks to hide a URL and a person must review the block first') and two explicit exclusions with the correct alternatives: listing goes to bing_blocked_urls, lifting goes to bing_plan_remove_blocked_url. This is explicit when/when-not/alternative guidance.

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

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.

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.

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.

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.

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.

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.

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

Annotations mark this as a non-readonly, non-destructive, open-world operation, but the description adds far more: it sends no change to Bing, only records intent, may consume quota, the user must not be told the change was applied, and the caller should return the plan id plus the CLI apply command. This is exactly the kind of side-effect and workflow disclosure annotations cannot express.

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?

The description is front-loaded with purpose, then usage, then behavioral caveats, and every sentence is directive rather than filler. It is slightly long due to three separate 'Do not' clauses, but each carries distinct, useful information.

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?

With no output schema, the description correctly tells the agent what to return (plan id and CLI apply command) and clarifies the non-mutating nature of the call. The remaining gap is the undocumented nested settings object, which leaves the agent unsure how to construct the geotargeting rule payload.

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% and the nested 'settings' object is entirely undocumented. The description implies site_url is the target URL and that settings carries a country/region targeting rule, which gives some semantic grounding, but it provides no format for the URL or structure/keys for the nested settings object, so it only partially compensates.

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 states a specific verb and resource: 'Record a plan to add a country or region targeting rule for a URL in Bing.' It also distinguishes itself from siblings by naming bing_geo_settings and bing_plan_remove_country_region_settings as not-this-tool. An agent can identify this as the plan-create variant for geotargeting rules 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 explicit positive conditions ('when the user wants a geotargeting rule and a person must review it first') and two explicit exclusions with the sibling to call instead for read and delete. Alternatives and selection conditions are fully specified.

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

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

Adds substantial behavior beyond the annotations: it declares this 'sends no change to Bing and only records intent', warns it 'may read your quota', and instructs the agent not to claim the change was applied but to return the plan id and CLI apply command. This is critical context the openWorld/readOnly/destructive hints cannot convey on their own.

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?

Front-loaded with the core action, then usage rules and alternatives, then agent instructions; almost every sentence is load-bearing. The 'do not tell the user.../return the plan id' sentence is directive rather than descriptive but earns its place by preventing a false success report.

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?

Covers purpose, when/when-not, alternatives, and the key planning semantics plus follow-up guidance for a mutation-adjacent tool with no output schema. The only meaningful gap is that the description never characterizes the four required parameters.

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 coverage is 0% for four required parameters, so the description must carry the full explanatory burden. It only implicitly maps three of them (deep link, search result, market) and never mentions site_url or gives any format/syntax guidance, so it does not compensate for the coverage gap.

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?

States a specific verb and resource ('Record a plan to block one deep link Bing shows under a search result in a market'), and immediately distinguishes this 'plan' tool from the sibling that actually lists blocks. An agent can tell it apart from bing_deep_link_blocks and bing_plan_remove_deep_link_block without opening a 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?

Gives explicit when-to-use ('user wants a deep link hidden and a person must review the block first') plus two explicit when-not cases naming the exact alternative tool for each (listing -> bing_deep_link_blocks, removal -> bing_plan_remove_deep_link_block). 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.

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

Annotations cover the safety profile, but the description adds substantial context beyond them: it clarifies the plan pattern ('sends no change to Bing and only records intent'), warns of a quota read, and instructs the agent not to claim the change was applied and to return the plan id plus the CLI apply command. This is exactly the intent-vs-application distinction an agent needs.

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?

Front-loads the purpose, then usage, then exclusions, then behavioral caveats. Every sentence adds distinct value; nothing is redundant or padded.

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?

No output schema exists, and the description explicitly states what to return (plan id and CLI apply command). Combined with the intent-vs-apply clarification and quota note, the agent has everything needed to call and report on this tool correctly.

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% and the description only implies the 'url' parameter via 'one URL'. It gives no meaning for 'site_url' and, more importantly, no explanation of the integer 'reason' parameter (presumably a code) despite it being required. With 3 required params at 0% coverage, the description does not compensate.

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?

States a specific verb+resource: 'Record a plan to block the page preview Bing shows for one URL.' It actively distinguishes itself from two named siblings (bing_page_preview_blocks, bing_plan_add_blocked_url), so an agent can route correctly 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?

Explicit when-to-use ('when the user wants a preview suppressed and a person must review it first') plus two explicit do-not-use cases naming the correct alternative tool for each. The condition that selects this tool over its alternatives is fully stated.

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

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

Goes well beyond the annotations: it discloses this sends no change to Bing, only records intent, may consume quota, and tells the agent not to claim the change was applied but to return the plan id and CLI apply command. That is unusually rich behavioral context for a non-readOnly tool.

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?

Front-loaded with the core action, then usage, then exclusions, then behavior and output handling. No sentence is filler; each adds a distinct constraint.

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?

No output schema exists, but the description compensates by describing what to return (plan id and CLI apply command) and explicitly warning the agent not to report the change as applied. Nothing needed for correct invocation is missing.

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 two required parameters (site_url, query_parameter), so the schema supplies no semantics. The description only implies what a query parameter is and never clarifies formats (e.g., whether to include the leading '?', full URL vs host) — a real gap when the schema is silent.

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?

States a specific verb+resource: 'Record a plan to add a query parameter Bing should know about for the site.' This clearly separates it from the remove/enable-disable variants among its many siblings.

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?

Gives explicit when-to-use ('when the user wants a URL parameter registered and a person must review it first') plus two explicit when-not-to-use rules naming the exact alternative tools (bing_query_parameters, bing_plan_enable_disable_query_parameter).

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

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

Adds critical context beyond annotations: 'This sends no change to Bing and only records intent; it may read your quota' and 'Do not tell the user the change was applied; return the plan id and the CLI apply command.' That clarifies the plan/apply separation and warns against a false success message, which annotations (readOnlyHint=false, idempotentHint=false) do not convey.

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?

Three tight sentences, front-loaded with the action, followed by the trigger condition, exclusions, and behavioral caveat. Every sentence carries routing or safety value with zero padding.

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?

For a one-param plan tool with no output schema, the description covers purpose, preconditions, exclusions, side-effect profile, and the expected follow-up (return plan id + apply command). Nothing an agent needs to call and handle the result correctly is missing.

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?

Only one parameter exists and schema description coverage is 0%, but the description says nothing about the site_url format (full URL vs host, scheme requirements, trailing slash). Baseline 3 applies for a 0-doc single-param tool where the description adds no parameter meaning.

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?

States a specific verb and resource ('Record a plan to add a site to the Bing Webmaster account'), and explicitly distinguishes itself from sibling planning tools by naming bing_sites_list and bing_plan_verify_site as the wrong tools for adjacent intents. An agent can route correctly 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?

Gives explicit when-to-use ('user wants a property registered and a person must review it first') and two explicit when-NOT-to-use clauses that name the correct alternative for each excluded intent. This is the textbook pattern.

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

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

Annotations only declare write/non-idempotent/open-world, but the description adds critical semantics: no change is sent to Bing, it records intent only, it may consume quota, and the agent must not claim the change was applied and instead must surface the plan id and CLI apply command. This is exactly the behavior an agent needs and cannot get from structured fields.

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?

Five short sentences, each with a distinct job: purpose, when to use, two exclusions, side-effect profile, and required output behavior. Purpose and routing are front-loaded; 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?

Behavior, side effects, and expected output are covered, which is strong for a plan-recording tool with no output schema. However, with six fully undocumented required parameters, an agent still cannot know what to supply for authentication_code or delegated_url, leaving the definition incomplete for invocation.

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?

All six required parameters have 0% schema description coverage, so the description carries the full burden, yet it never explains authentication_code, delegated_url, or the is_administrator/is_read_only distinction. Only 'one email address' implicitly points at user_email. With a 6-param required-only schema and no coverage, this is a significant gap.

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?

States a specific verb and resource ('Record a plan to delegate access to a Bing Webmaster site for one email address') and immediately distinguishes itself from the read-only sibling bing_site_roles and the inverse sibling bing_plan_remove_site_role. An agent can select this tool 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?

Explicit when-to-use ('when the user wants access granted and a person must review the delegation first') plus two explicit when-not-to-use clauses that name the correct alternative tools. Nothing is left to inference about routing.

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

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

Annotations declare the safety profile, and the description adds genuinely non-obvious behavior: it sends no change to Bing, only records intent, may consume quota, and the agent must not claim the change was applied but instead return the plan id plus a CLI apply command. This is exactly the contextual disclosure 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.

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

Front-loaded with purpose followed by exclusions and then behavioral warnings; every sentence earns its place. It is dense with four distinct directives, which is slightly heavy but justified for a plan/apply workflow.

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?

No output schema exists, and the description explicitly tells the agent what to do on return (return the plan id and CLI apply command). Combined with plan semantics and quota warning, the agent has everything needed to call and report correctly.

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 three required parameters, so the description carries the full burden. It implies the target (site, query parameter, enable/disable) through its purpose statement but never documents site_url format, query_parameter syntax, or the enable-vs-disable meaning of is_enabled.

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?

States a specific verb+resource+scope: 'Record a plan to enable or disable a query parameter Bing already has for the site.' It explicitly distinguishes itself from two named siblings (bing_plan_add_query_parameter and bing_query_parameters), so an agent can route correctly 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?

Gives explicit when-to-use ('when the user wants a parameter toggled and a person must review it first') and two when-not-to-use clauses, each pointing at the correct alternative tool. 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.

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

Annotations only give generic hints (readOnlyHint=false, openWorld=true), while the description adds quota consumption on apply, that this call sends no change to Bing and only records intent, that it may read quota, and an explicit instruction not to tell the user the change was applied. That is behaviorally rich context the annotations cannot convey.

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?

Front-loaded with the action, then the cost, then the routing rules and the return-value guidance; every sentence carries information. The two parallel 'Do not use this…' sentences are slightly repetitive but justified by the dense sibling set.

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?

Covers the plan/apply lifecycle, quota cost, non-effects on Bing, and what to return (plan id plus CLI apply command) despite there being no output schema. Only the parameter meanings are left uncovered, which keeps it short of complete for a 2-param 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% and neither 'url' nor 'site_url' is explained in the description, leaving the distinction between the target URL and the verified site property entirely undocumented. The description adds no parameter meaning beyond the schema, and with zero coverage it should compensate but does not.

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?

States a specific verb and resource — 'Record a plan to ask Bing to fetch one URL' — and immediately clarifies the two-step plan/apply model. It distinguishes itself from bing_url_info and bing_plan_submit_url by name, so an agent can route without opening sibling schemas.

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?

Explicit positive condition ('when the user wants a recrawl and a person must review the quota spend first') plus two explicit exclusions with the correct alternatives named for each. Nothing is left to inference about when to choose this tool.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description is consistent with them: it is a non-destructive write that only records intent. It adds genuinely useful context beyond the annotations — that no change is sent to Bing, that quota may be read, and that the agent must not claim the change was applied. However, it does not say whether repeated identical calls create duplicate plans (relevant given idempotentHint=false) or what happens to a plan that is never applied. With annotations carrying safety, a 3 is appropriate.

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?

Front-loaded with purpose and trigger before the exclusions, and every sentence carries routing or behavioral weight. It is on the long side for a description, with the exclusions restated as separate sentences, but nothing is 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, and the description covers the return contract itself: return the plan id and the CLI apply command, and do not tell the user the change was applied. For a plan-recording tool with a required follow-up human step, that is exactly the missing information an agent needs.

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%, so the description must carry the load. It implies semantics for two of four parameters ('one host' constrains host; 'batch of URLs' describes url_list) and the key-file exclusion hints at what `key` is, but `key` versus `key_location` — the distinction an agent is most likely to get wrong — is never explained. Partial compensation only.

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?

States a specific verb and resource ('Record a plan to submit a batch of URLs to IndexNow ... for one host') with the target endpoint named. It explicitly distinguishes itself from three siblings (bing_indexnow_key_plan, bing_plan_submit_url, bing_plan_submit_url_batch), so an agent can route 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?

Gives the positive trigger ('use when the user wants an IndexNow submission and a person must apply it first') plus two explicit exclusions with the correct alternatives named for each. Nothing about when-not-to-use 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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), but the description adds genuine non-obvious context: verification and delegation secrets in plan arguments are returned redacted, and the redaction does not affect plan execution. That is real behavioral disclosure beyond structured fields, though it doesn't cover pagination or list size limits.

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?

Three tight sentences, front-loaded with the action, then usage routing, then the caveat. No filler and each sentence carries distinct information.

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?

No output schema exists, so the description has to convey return content; it names the plan states (waiting/applied/expired) and the redaction behavior, which is enough to call and interpret the tool. It stops short of describing ordering, pagination, or the full state enum.

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?

The tool takes no parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline for zero-param tools applies.

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?

States a specific verb and resource ('List recorded plans and their current states') and explicitly contrasts itself with the sibling bing_plan_show. An agent can distinguish it from the ~40 other bing_plan_* tools without opening a 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?

Gives an explicit trigger ('when the user asks which changes are waiting, applied or expired') and an explicit exclusion with the named alternative ('Do not use this to read one plan's arguments; call bing_plan_show'). Routing is unambiguous.

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

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

Adds substantial behavior beyond the annotations: it sends no change to Bing and only records intent, it may consume quota, and it instructs the agent not to claim the change was applied but to return the plan id and CLI apply command. That is exactly the kind of plan-vs-apply semantic an agent cannot infer from readOnlyHint/openWorldHint alone.

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?

Front-loads the action and effect, then the usage rules and behavioral caveats; nearly every sentence earns its place. It is dense with imperatives but not padded, so it reads efficiently.

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?

No output schema exists, and the description usefully states what to return (plan id and CLI apply command) plus the plan-vs-real-change distinction. The only material gap is the unexplored parameter shape, which matters given the nested required object.

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% and the description never mentions site_url or the nested blocked_url object at all. With an undocumented required nested object, the description does not compensate for the coverage gap, leaving the agent to guess the expected shape of blocked_url.

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?

States a specific verb and resource ('Record a plan to remove one URL block request') and clarifies the intended effect (Bing may show the URL or its cached copy again). It also names the sibling tools for the adjacent operations, so an agent can distinguish it from bing_plan_add_blocked_url and bing_blocked_urls 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?

Explicitly gives the when ('user asks to unblock a URL and a person must review it first') and two when-nots with the correct alternatives (add a block -> bing_plan_add_blocked_url; see current list -> bing_blocked_urls). Nothing about tool selection 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.

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

Adds substantial behavioral context beyond the annotations: it 'sends no change to Bing and only records intent,' may consume quota, and the agent must not claim the change was applied but instead return the plan id plus the CLI apply command. This clarifies the write-but-not-applied semantics that the raw readOnlyHint=false / destructiveHint=false flags cannot convey on their own.

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?

Six short clauses, each carrying load-bearing information: purpose, precondition, two exclusions with alternatives, side-effect/behavior, and required agent response. The most consequential fact (no change is sent) is positioned before the caller-facing instructions.

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?

For a plan-recording mutation with no output schema and no annotation detail, the description covers behavior, side effects, quota, review requirement, and the required follow-up action. The one missing piece is the shape of the nested settings object, though the description implies what it targets.

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%, and the description gives no guidance on either parameter. It hints at the subject matter (a country/region rule) and 'site_url' is self-evident, but the nested 'settings' object is entirely unspecified in both schema and description, which is a real gap when coverage is this low.

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?

States a specific verb and resource: 'Record a plan to remove a country or region targeting rule from Bing.' It is immediately distinguishable from the add-rule sibling and from read tools like bing_geo_settings.

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?

Explicit when-to-use ('user wants a geotargeting rule removed and a person must review it first') plus two explicit when-not-to-use cases, each naming the correct alternative tool (bing_plan_add_country_region_settings for adds, bing_geo_settings for reads). 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.

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

Adds substantial context beyond the annotations: it sends no change to Bing and only records intent, it may consume quota, and it instructs the agent to return the plan id plus the CLI apply command rather than telling the user the change was applied. These are non-obvious behavioral traits that the readOnlyHint=false annotation alone would not convey.

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?

Purpose is front-loaded in the first clause, followed by usage conditions, alternatives, behavioral caveats, and a return-handling instruction. Every sentence carries distinct information with no filler or repetition.

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?

For a four-parameter plan-recording tool with no output schema, the description covers what it does, when to use it, what it does not do, its side effects (quota), and what to return to the caller. Nothing needed for correct invocation is missing.

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% and the description explains none of the four required parameters (site_url, market, search_url, deep_link_url). While the names are largely self-describing, there is no guidance on formats, market codes, or what search_url vs deep_link_url must contain — a real gap the description should have closed.

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?

States a specific verb ('Record a plan to remove') plus the exact resource ('a deep-link block') and its effect ('so Bing may show that link again'). It also distinguishes itself from adjacent siblings by name, so an agent can route correctly 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?

Gives explicit when-to-use ('user wants a deep link restored and a person must review it first') and two explicit when-not cases with the correct alternatives (bing_plan_add_deep_link_block for adding, bing_deep_link_blocks for listing). 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.

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

Annotations exist but only declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds non-obvious operational context the annotations cannot convey: it sends no change to Bing (two-phase plan/apply model), it may read your quota, and the agent must not claim the change was applied but return the plan id and CLI apply command. This is exactly the value-add the annotations cannot provide, and it is self-consistent with readOnlyHint=false (a local plan record is written).

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?

The core action is front-loaded in the first sentence, followed by routing guidance and then behavioral constraints. Every sentence earns its place; 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?

No output schema exists, so the description carries the return-value burden and does so precisely ('return the plan id and the CLI apply command'). Combined with the two-phase workflow explanation, an agent has everything needed to call and report the tool correctly.

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 two parameters, so the description must compensate. It implicitly maps 'sitemap URL' to feed_url but never names feed_url or site_url or their expected format, and site_url is entirely unaddressed. With only two simple, understandably-named required params this is adequate but leaves real format ambiguity.

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?

States a specific verb and resource: 'Record a plan to remove a sitemap URL from Bing.' It goes further by naming the sibling it is not (bing_plan_submit_feed for adding) and the sibling for reading status (bing_sitemap_details), so it is unmistakable among the ~40 bing_plan_* tools.

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?

Gives explicit when-to-use ('user wants a sitemap removed and a person must review it first') and two explicit when-not-to-use clauses with the exact alternative tool to call instead. 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.

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

Annotations only say readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds the crucial two-phase workflow semantics: no change is sent to Bing, it only records intent, it may read quota, and the agent must not tell the user the change was applied but instead return the plan id and CLI apply command. That is behavior the annotations cannot convey.

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?

Front-loaded with purpose and outcome, then usage, then prohibitions, then behavioral caveats and the required output instruction. Every sentence carries distinct information with no repetition.

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, and the description explicitly covers the return value (plan id plus the CLI apply command) and the non-application caveat. Combined with the routing guidance, an agent has everything needed to call and report on this tool correctly.

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 two required parameters (site_url, url), so the schema does no explanatory work. The description never mentions either parameter, their expected format, or how site_url relates to url, so it fails to compensate for the coverage gap.

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?

States a specific verb and resource ('Record a plan to remove a page-preview block') plus the outcome ('so Bing may show a preview again'). It explicitly separates itself from the add sibling and the list sibling, so an agent can route 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?

Gives explicit when-to-use ('user wants a preview restored and a person must review it first') and two when-not-to-use clauses naming the exact alternative tools (bing_plan_add_page_preview_block, bing_page_preview_blocks). 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.

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

Goes well beyond the annotations by disclosing the plan/apply workflow: it 'sends no change to Bing and only records intent', 'may read your quota', and instructs the agent not to claim the change was applied but to return the plan id and CLI apply command. This resolves the ambiguity created by readOnlyHint=false, which alone would suggest a Bing-side mutation.

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?

Front-loads the core action, then layers usage and when-not routing, then behavioral caveats. Every sentence earns its place with no redundancy despite the length.

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?

For a plan-recording tool with no output schema, the description covers the workflow, quota side effect, and what to return to the user. The remaining gap is parameter format detail, which the 0%-coverage schema does not supply.

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 coverage is 0% with two required parameters, so the description must carry the burden. It only implies that query_parameter is the parameter to delete and site_url identifies the site; it gives no format guidance (e.g., bare parameter name vs. full URL, site_url syntax), leaving both params under-specified.

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?

States a specific verb+resource ('Record a plan to remove a query parameter from the site's Bing configuration') and immediately delineates against siblings: adding (bing_plan_add_query_parameter) and listing (bing_query_parameters). An agent can distinguish it from the ~50 sibling 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?

Explicit when-to-use ('when the user wants a URL parameter deleted and a person must review it first') plus two named when-not cases routing to the correct alternatives. 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.

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

Goes well beyond the annotations by disclosing that no change is sent to Bing, that it only records intent, that it may read quota, and that the agent must not claim the change was applied but instead return the plan id and CLI apply command. The readOnlyHint=false is clarified rather than contradicted, since the tool writes local plan state.

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?

Front-loaded with the purpose, then tightly ordered use/exclusion/behavior sentences. Five sentences is a bit dense, but each carries distinct, non-redundant information.

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?

Despite no output schema, the description explains what to return (plan id and CLI apply command) and warns about the quota side effect, so an agent has everything needed to call and follow up correctly.

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?

Only one parameter with 0% schema description coverage, and the description refers to 'a site' without specifying the expected site_url format (full URL vs. domain, trailing slash, etc.). The single param is near self-documenting, so this is minimally adequate but does not compensate for the coverage gap.

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?

States a specific verb and resource ('Record a plan to remove a site from the Bing Webmaster account'), making the deferred-plan nature explicit. It distinguishes itself from write siblings and from the read-only listing tool without requiring the 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?

Gives an explicit use condition ('when the user wants a property removed and a person must review it first') and two named exclusions with the alternative to call instead (bing_plan_add_blocked_url for one URL, bing_sites_list for viewing). 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.

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

Goes well beyond the annotations: it discloses that no change is sent to Bing, that only intent is recorded, that quota may be read, and that the caller must return the plan id and a CLI apply command rather than telling the user the change was applied. That is precisely the post-call behavioral contract an agent needs and cannot infer from readOnlyHint/destructiveHint alone.

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?

Front-loaded with the core action, then usage, exclusions, behavioral caveats, and the required response handling, in that order. Every sentence carries distinct information; none is redundant with the annotations or schema.

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?

Behaviorally the definition is thorough and there is no output schema to explain, so return-value concerns are covered. The gap is the completely undocumented nested site_role parameter, which the description never unpacks despite the schema offering no help.

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% and one parameter is a nested object (site_role) with no structure disclosed anywhere. The prose implies the meaning of site_url and site_role at a high level ('one delegated role from a Bing Webmaster site'), but gives no identifier format, no role vocabulary, and no detail on the nested object's fields, so it does not compensate for the coverage gap.

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 states a specific verb and resource: 'Record a plan to remove one delegated role from a Bing Webmaster site.' It immediately distinguishes itself from the two nearest siblings by naming them (bing_plan_add_site_roles for granting, bing_site_roles for listing), so an agent can separate it from the crowded bing_plan_* family without opening a 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?

Explicit when-to-use ('when the user wants access revoked and a person must review it first') plus two explicit when-not-to-use clauses with the correct alternative tool named for each. This is about as complete as routing guidance gets.

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

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

Goes well beyond the annotations: it discloses that no change is sent to Bing, that the call only records intent, that it may consume quota, and that the caller must not report the change as applied. These are consequential behavioral facts the readOnlyHint/destructiveHint flags do not convey on their own.

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 tight sentences, front-loaded with the core action, then usage condition, then exclusion, then behavioral caveats. Every sentence carries non-redundant information.

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?

Covers the workflow (plan id plus CLI apply command as the return) and the key behavioral nuance for a plan tool. The remaining gap is the unexplained nested crawl_settings structure, which matters for correctness but is not addressed anywhere.

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% and the description never mentions site_url or crawl_settings directly. The nested crawl_settings object is completely undocumented in both schema and description, so the agent gets no field-level guidance for the most complex parameter; the phrasing only loosely implies the two params.

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?

States a specific verb and resource ('Record a plan to replace the site's crawl settings in Bing') and implicitly scopes it as an intent-recording tool rather than a live mutation. An agent can distinguish it from bing_crawl_settings and the other bing_plan_* siblings without opening the 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?

Gives an explicit when-to-use ('the user wants crawl settings changed and a person must review them first'), an explicit when-not ('Do not use this to read the current settings'), and names the alternative tool (bing_crawl_settings). Nothing is left to inference about selection.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: that the tool never applies the plan, and that verification/delegation secrets in the returned arguments are replaced with a redaction placeholder while the plan still applies with the real value — a non-obvious output quirk an agent would otherwise misread.

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 sentences, each doing distinct work: purpose, non-mutation guarantee, routing rule, redaction caveat. Front-loaded with the core action. Slightly dense but no sentence is 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?

No output schema exists, so the description correctly explains what comes back (the plan's arguments and the applying command). Combined with annotations covering safety, an agent has everything needed to select and invoke this tool correctly.

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?

There is one required parameter (plan_id) at 0% schema description coverage, so the description carries the burden. It implies the identifier selects 'one recorded plan' but never states the format, source, or where an agent obtains a valid plan_id, leaving the parameter largely undocumented.

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?

States a specific verb and resource ('Show one recorded plan for review') and immediately scopes it with 'This never applies it.' It also explicitly distinguishes itself from the closest sibling (bing_plan_list) rather than leaving that inference to the agent.

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?

Gives an explicit positive trigger ('when the user wants one plan's arguments and the command that would apply it') and an explicit negative one ('Do not use this to list every plan; call bing_plan_list'), naming the alternative by name. Both the when and the when-not are covered.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, but the description adds critical context they don't: no change is sent to Bing, it only records intent, it may read the quota, and the agent must not tell the user the change was applied. It also specifies the correct success behavior (return plan id + CLI apply command).

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?

Front-loaded with purpose, then routing exclusions, then behavior and output guidance. Every sentence carries a distinct fact; nothing is redundant or restated from the annotations.

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?

With 0% schema coverage, five required parameters, and no output schema, the description should at minimum sketch the inputs, but it provides no parameter detail. Its excellent behavioral and routing coverage does not compensate for the missing input semantics on a non-trivial 5-param call.

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% across five required parameters, so the description carries the full burden and mostly fails. It mentions 'structured data' and quota reads in passing but never explains http_message, dynamic_serving, or the expected format of structured_data, leaving the agent to guess at required input shapes.

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?

States a specific verb and resource: 'Record a plan to submit a page's content to Bing, including structured data.' It explicitly distinguishes itself from the nearest siblings (bing_plan_submit_url for ordinary URL submission, bing_content_submission_quota for reading quota), so an agent can route without opening another 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?

Gives both the positive trigger ('when the user wants the page body submitted and a person must review it first') and two explicit exclusions with named alternatives. Nothing about when to pick this over bing_plan_submit_url 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.

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

Annotations only declare the generic profile (not read-only, open-world, not idempotent, non-destructive). The description goes well beyond that: it states no change reaches Bing, only intent is recorded, quota may be read, and it gives a directive about what to report back to the user and what to return. That is exactly the behavioral context annotations cannot convey.

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?

Short imperative sentences, front-loaded with purpose then routing then behavioral caveats. Every clause carries decision-relevant information; there is no filler or repetition.

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?

For a two-param, no-output-schema planning tool, the description covers the entire lifecycle: what it records, what it does not do, what to return (plan id and CLI apply command), and what not to tell the user. Nothing an agent needs to call and report correctly is missing.

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 coverage is 0%, so the description carries the full burden. It obliquely maps 'sitemap URL' onto feed_url but never explains what site_url means or how the two relate (e.g., which site the feed belongs to, URL format expectations). With two required, undocumented parameters, the description does not compensate for the coverage gap.

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?

Specific verb+resource: 'Record a plan to submit a sitemap URL to Bing.' It immediately distinguishes itself from the two closest siblings by name (bing_sitemaps for listing, bing_plan_remove_feed for removal). An agent knows exactly what this tool does 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?

Explicit when-to-use ('when the user wants a sitemap added and a person must review it first') plus two named when-not alternatives, each paired with the sibling to call instead. Nothing about routing 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.

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

Goes well beyond the annotations: it discloses that no change is sent to Bing and only intent is recorded, that it may read the quota, that human review is required, and exactly how the agent should behave (return the plan id and CLI apply command; do not claim the change was applied). This is rich, actionable behavioral disclosure for a mutation-planning tool.

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?

Front-loaded with the purpose, then usage, then behavior and return guidance. Sentences are dense and mostly earn their place, though the agent-directed instructions ('Do not tell the user...') add length beyond a pure tool description.

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?

With no output schema, the description correctly explains what to return (plan id + CLI apply command) and fully covers side effects and review flow. The only meaningful gap is parameter/input semantics for the required nested settings object.

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?

The schema has 0% description coverage and a nested 'settings' object, yet the description says nothing about what site_url should contain or what keys 'settings' expects. For a 2-parameter tool with an undocumented nested object, the description needed to compensate and does not.

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?

States a specific verb and resource: 'Record a plan to submit a site move so Bing treats one address as moved to another.' It also names the sibling it is not (bing_site_moves), so an agent can distinguish it from the read-side tool without opening a 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?

Explicit when-to-use ('when the user wants a migration submitted and a person must review it first') and explicit when-not-to-use with the alternative ('Do not use this to see moves already recorded; call bing_site_moves'). 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.

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

Goes well beyond the annotations by disclosing that it 'sends no change to Bing and only records intent', that it may read quota, and that the human-review gate precedes any submission. It also instructs the agent not to report the change as applied and to return the plan id plus CLI apply command — critical behavioral framing that annotations (readOnlyHint=false, destructiveHint=false) cannot convey. No contradiction with annotations, since recording a plan is legitimately a non-read-only action.

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?

Front-loaded with the core action, then constraints, then behavioral warnings, then the required agent response. Every sentence carries unique, actionable information with 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?

Complete on behavior and return handling (plan id + CLI apply command) despite no output schema, and safety implications are clear. The only shortfall is the undefined parameter vocabulary, which leaves the agent guessing about site_url vs url semantics.

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 coverage is 0% and neither 'site_url' nor 'url' is documented anywhere. The description only weakly implies a site/page distinction ('one page', 'one URL') without defining formats or the relationship between the two parameters. For a 2-required-param tool this is a real gap the description fails to fill.

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?

States a specific verb ('Record a plan to submit'), resource (one URL), and target system (Bing for crawling and indexing), plus the scope limit ('one URL'). It explicitly distinguishes itself from bing_plan_submit_url_batch, so an agent can route correctly without opening either 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?

Gives explicit when-to-use ('user wants one page submitted and a person must review it') and two explicit when-not-to-use cases with named alternatives: bing_plan_submit_url_batch for many URLs, bing_submission_quota for quota reads. 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.

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

Annotations only supply the generic flags (readOnlyHint=false, openWorldHint=true, non-idempotent); the description goes well beyond by disclosing that no change is sent to Bing, that the call only records intent, that it may read quota, and by giving agent-facing reporting rules (return the plan id and CLI apply command; do not tell the user the change was applied). This is exactly the kind of side-effect and follow-through detail annotations cannot convey, and it does not conflict with them.

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?

Front-loaded purpose followed by when-to-use, two exclusions, behavioral caveats, and the reporting instruction — every sentence carries distinct information with no repetition.

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?

With no output schema, the description usefully covers the return contract (plan id plus CLI apply command) and the safety profile of the plan step. The only real gap is the absence of batch-size or URL-format guidance for a tool whose whole purpose is bulk submission.

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% and neither parameter is explained beyond the implication that url_list is a list of URLs for site_url. No format constraints, URL canonicalization rules, batch size limits, or whether site_url must match the URLs are stated, so the description does not compensate for the schema gap.

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?

States a specific verb and resource ("Record a plan to submit a list of URLs to Bing in one batch") and immediately scopes it as the batch variant, distinguishing it from the single-URL sibling bing_plan_submit_url. An agent can route between the two without opening either 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?

Explicit when-to-use (several pages need batch submission plus human review) and two explicit when-not cases with named alternatives: bing_plan_submit_url for one URL and bing_submission_quota for quota reads. 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.

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

Goes well beyond the annotations by disclosing that no change is sent to Bing, that only intent is recorded, that quota may be read, and that the agent must not tell the user the change was applied. It also specifies the return contract (plan id plus CLI apply command). Annotations (readOnlyHint false, openWorldHint true) alone would not let an agent infer any of this.

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 tight sentences, each doing distinct work: purpose, positive usage condition, two exclusions with alternatives, behavioral caveats, and output instruction. 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.

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

No output schema exists, and the description compensates by stating exactly what to return (plan id and CLI apply command) and what not to claim to the user. Combined with the plan-then-apply workflow caveats and quota note, an agent has everything needed to call and report on 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?

Only one parameter (site_url) with 0% schema description coverage, and the description supplies no format, syntax, or validation detail for it. The phrase 'a site that is already on the account' loosely implies the URL must be a registered property, but that is the only hint about what value to pass.

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?

States a specific verb and resource ('Record a plan to ask Bing to verify a site that is already on the account'), including the crucial scope qualifier that the site must already exist on the account. This immediately separates it from the add-site plan tool without opening either 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?

Gives explicit when-to-use ('when the user wants Bing to check verification and a person must review it first') and two explicit when-not-to-use cases with named alternatives ('Do not use this to add the site; call bing_plan_add_site' and 'Do not use this to read the verification secret; no MCP tool returns one'). This is textbook routing guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds genuinely non-obvious behavior: the empty_response label semantics and the rule that untrusted fields must be treated as data, not instructions. It omits rate limits and auth requirements, but the added operational caveats are substantive.

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?

Purpose is front-loaded, then usage routing, then two operational caveats. All four sentences carry distinct, actionable information, though the density of caveats in the back half makes it slightly long for a single-read description.

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 and no parameter documentation, so the agent learns nothing about the shape of the returned time-series (fields, granularity) beyond the empty-response case. The description covers the most important behavioral gotcha, but leaves the return contract and parameter formats unstated.

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%, so all three required parameters (site_url, query, page) are undocumented anywhere. The prose implies each parameter's meaning but never specifies formats — e.g., whether 'page' is a full URL or a path, or what form site_url takes. With low coverage the description should compensate and does not.

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 first sentence gives a specific verb ('Read'), resource ('Bing traffic over time'), and scope ('one search query on one page'), which is exactly what distinguishes it from sibling traffic tools. It also explicitly names the sibling it must not be confused with, so an agent can route 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 states the triggering condition ('when the user asks how a specific page performs for a specific query') and the exclusion ('do not use this to list every page for the query'), naming bing_query_page_stats as the alternative. This is explicit when/when-not/alternative guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is covered. The description goes further with two non-obvious behaviors: an empty_response label meaning 'silence, not a measurement' that must never be reported as 'no problems found', and a prompt-injection rule to treat untrusted fields as data. It stops short of describing pagination or limits, but the added behavioral context is substantial.

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?

Front-loaded purpose sentence followed by usage, exclusions and caveats, with zero filler. Every sentence carries routing or behavioral information an agent actually needs.

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 should describe the returned page rows, but it only names the empty_response label and the untrusted-field convention. The agent learns nothing about which metrics come back (impressions, clicks, position) for a stats 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%, so the description carries the burden for both parameters. It does convey that site_url identifies the single site and query is the search query, but it gives no format, expected encoding, or matching semantics, leaving the agent to infer the rest.

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?

States a specific verb, resource and cardinality: 'List the pages on one site that Bing showed for one search query.' The scope (one site, one query, list of pages) immediately separates it from the detail, trend and traffic 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.

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

Gives an explicit positive trigger ('Use when the user asks which URLs rank for a query') plus two named exclusions with their alternatives: bing_query_page_detail_stats for a single page's series and bing_traffic_query for site-wide trend. Routing is unambiguous.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds two genuinely new behavioral traits: the empty_response label meaning silence rather than a measurement, and the instruction to treat untrusted fields strictly as data. These are material operating semantics an agent cannot get from the structured fields.

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?

Front-loaded with purpose, then usage, then the alternative, then the safety/empty-response caveats. Dense but every sentence earns its place and follows a logical order.

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?

With no output schema, the description supplies the critical return behavior (empty_response label) and safety posture, plus explicit routing to a sibling. An agent has everything needed to call it and interpret results correctly.

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% with a single required param, so the description must carry the burden; it only implies single-site scoping ('for one site') and gives no format or validity guidance for site_url. Some added meaning, but incomplete compensation for the coverage gap.

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?

States a specific verb (List) and resource (query parameters Bing has configured for one site), with explicit scope. It names a sibling it is not to be confused with (bing_geo_settings), so the agent can distinguish it without opening the 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?

Gives both when-to-use (the user asks which URL parameters Bing knows about) and when-not-to-use, with a concrete alternative named ('call bing_geo_settings'). 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.

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

Beyond the readOnly/idempotent annotations, it discloses that the call is not site-scoped, defines the empty_response label and forbids interpreting it as 'no problems found', and mandates treating untrusted-marked fields as data rather than instructions. These are non-obvious behaviors an agent cannot derive from the annotations.

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?

Purpose leads, routing exclusions follow, and the caveats about empty results and untrusted data close it out. Every sentence carries distinct operational value with no restatement of the name or redundant framing.

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?

With no output schema, the description carries the return-value burden and does cover the important edge case (empty_response) and field trust handling. It stops short of describing the general shape of a successful result, which is the only remaining gap for a 5-param read 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% across 5 required parameters, and the description only maps them conceptually ('one query in a country and language over a date range'). It does not state expected formats for country, language, or the date fields, so an agent still has to guess at code conventions despite the conceptual coverage.

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 first sentence states a specific verb and resource ('List keywords Bing relates to one query') and adds the scoping dimensions (country, language, date range). It explicitly distinguishes itself from bing_keyword_stats and bing_keyword, so an agent can route correctly 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 the positive trigger ('when the user asks which other queries sit next to a keyword') and two explicit exclusions naming the correct alternatives, closing the two most plausible mis-routes (keyword history, impressions over time). Nothing about selection 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.

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

Beyond annotations that mark this as a safe read, the description adds critical behavioral context: an empty response is silence rather than a measurement and must not be reported as 'no problems found.' It also warns to treat untrusted fields as data, not instructions.

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?

The description is four dense sentences with no wasted text. Purpose, usage, exclusions, and behavioral caveats are front-loaded and easy to scan.

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?

For a simple read tool with no output schema, the description covers usage, exclusions, empty-response semantics, and untrusted-field handling well. It is only incomplete on parameter meanings, a gap that matters because the schema provides no descriptions.

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 coverage is 0% for two required parameters, so the description must compensate. It never explains the roles or formats of site_url and feed_url, only referring vaguely to 'one sitemap URL,' which leaves the parameter semantics largely undocumented.

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 states a specific verb and resource: 'Read Bing's status for one sitemap URL.' It clearly distinguishes this from bing_sitemaps by explicitly saying not to use it for listing every sitemap.

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 explicit when-to-use guidance ('when the user asks whether a specific sitemap was fetched or how many URLs it has') and a named alternative for the excluded case ('Do not use this to list every sitemap; call bing_sitemaps').

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

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive). The description adds what annotations cannot: the empty_response label means silence rather than a measurement and must not be reported as 'no problems found', plus a prompt-injection guard on untrusted fields. Both are genuine behavioral disclosures.

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 ordered by importance: purpose, trigger, alternative, then the two safety caveats. No filler, nothing repeated from the schema.

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?

No output schema exists, so the description carries the return-value burden and does so by explaining the empty_response case. Combined with the sibling routing and injection warning, an agent has everything needed to call and report on this tool correctly.

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% and the single required parameter site_url is never mentioned in the description. 'For one site' hints that the parameter scopes to a site, but the expected format (domain vs. full URL, protocol, subdomain handling) is left entirely undocumented.

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?

States a specific verb and resource ('List the sitemaps Bing has for one site') and explicitly distinguishes itself from the nearest sibling, bing_sitemap_details. An agent can route between the two without inspecting either 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?

Gives an explicit trigger ('Use when the user asks which sitemaps are submitted') and an explicit exclusion with the correct alternative ('Do not use this for one sitemap's status; call bing_sitemap_details'). This is the full when/when-not/alternative pattern.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds genuinely non-obvious behavior: the empty_response label and the strong warning that silence must not be reported as 'no problems found', plus an untrusted-data-handling instruction. It doesn't cover pagination or result size, but for this read-only tool the extra semantics are valuable.

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?

Five tight sentences, front-loaded with purpose before the alternative and the empty_response caveat. No filler; each sentence carries distinct routing, behavioral, or safety information.

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?

Given no output schema and one undocumented param, the description is close to complete: it explains the empty-result case and the untrusted-data rule. The only gap is site_url format guidance, which is the one thing an agent could get wrong before calling.

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?

The schema has one parameter (site_url) with 0% description coverage, so the description carries the burden. It implies the tool operates on 'one site' but never clarifies the expected site_url format (full URL vs hostname). Baseline 3 given a single param, though the format gap is the main miss.

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?

States a specific verb and resource ('List site-move requests Bing has recorded for one site') with precise scope ('for one site'). It explicitly distinguishes itself from the sibling bing_sites_list, so an agent can route without opening either 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?

Gives an explicit when-to-use ('when the user asks whether a domain or URL migration was already submitted') and an explicit when-not ('Do not use this for the account's site list; call bing_sites_list'). The alternative is named with the condition that selects it.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses that DelegatedCode is redacted and CLI-only, that an empty result carries an empty_response label meaning 'silence, not a measurement', and that untrusted fields are data never instructions. This is exactly the extra behavioral context annotations cannot encode.

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?

Front-loaded with purpose, then usage routing, then behavioral caveats in a logical order; each sentence adds a distinct fact. Slightly dense but nothing is 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, and the description compensates by explaining the empty_response label and the redacted DelegatedCode field. The remaining gap is the undocumented include_all_subdomains parameter, which keeps it short of full completeness for a two-parameter 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 two parameters, so the schema does no lifting and the description must compensate. It implies a single site (site_url) but says nothing about the format of site_url or what include_all_subdomains does (whether it recurses into subdomains' delegations), leaving a meaningful parameter entirely undocumented.

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?

States a specific verb (list) plus resource (people and roles delegated) and scope (one Bing Webmaster site). It also names the sibling it is not (bing_sites_list), so an agent can distinguish it 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?

Gives explicit trigger conditions ('who has access to a site', 'which role an account holds') and an explicit exclusion with the alternative to use instead ('Do not use this to discover which sites exist; call bing_sites_list'). 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.

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it discloses that verification secrets (AuthenticationCode, DnsVerificationCode) are redacted and unreachable via any MCP tool, that an empty result carries an empty_response label meaning silence rather than a clean bill of health, and that certain fields are untrusted data. These are real behavioral constraints an agent could not infer from the schema or annotations.

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?

Front-loaded correctly: purpose, then usage, then the sibling exclusion, then return shape, with the safety caveats after. It is longer than most definitions and the operator CLI/UI detail is slightly tangential, but nearly every sentence addresses a distinct decision the agent must make, so the length is mostly earned.

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?

With no output schema, the description carries the full burden and does so: it enumerates the returned fields, explains the redaction of sensitive fields, and defines the empty-response edge case so it cannot be misreported. Nothing an agent needs to call and interpret this tool correctly is missing.

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?

The tool takes zero parameters, so per the baseline this is a 4. The description does describe the shape of what comes back (one entry per site, Url and IsVerified), which is useful, but there are no parameter semantics to add beyond that.

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?

Opens with a specific verb and resource ('List every site on the Bing Webmaster account') and immediately adds scope detail ('with its URL and whether it is verified'). It explicitly names the sibling it must not be confused with (bing_site_roles), so an agent can distinguish it without opening another 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?

Gives an explicit when ('the user asks which sites this account owns or whether a property is verified') and an explicit when-not with the correct alternative ('Do not use this to see who can edit a site; call bing_site_roles'). Both the positive trigger and the exclusion route to a specific sibling.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds genuinely new behavioral context: an empty result returns an 'empty_response' label that is silence rather than a measurement and must not be reported as 'no problems found', plus a prompt-injection directive about untrusted fields. That is exactly the kind of semantics annotations cannot express.

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?

Front-loaded with purpose, then usage, then the exclusion, then two output-safety caveats. Every sentence carries weight, though the closing untrusted-data directive is somewhat generic boilerplate that could be shared across the whole tool family rather than repeated here.

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?

With no output schema, the description still discloses return semantics: a quota count plus the 'empty_response' labeling for the empty case and untrusted-field handling. For a single-parameter read tool, nothing an agent needs to interpret the result correctly is missing.

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% and the sole parameter site_url is never characterized in the description beyond the vague phrase 'for one site.' It does not say whether the value is a bare domain, a full URL, or a site identifier, leaving the one input an agent must supply under-specified in both schema and prose.

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?

States a specific verb and resource with scope: 'Read how many URL submissions Bing still allows for one site today.' It explicitly distinguishes itself from the sibling bing_content_submission_quota, so an agent can route without opening either 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?

Names the triggering condition ('when the user asks whether a URL or a batch can still be submitted') and an explicit exclusion with the alternative to use instead ('Do not use this for content-submission quota; call bing_content_submission_quota'). This is the full when/when-not/alternative pattern.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: an empty_response label that must not be reported as 'no problems found', and a prompt-injection rule that untrusted fields are data only. This is exactly the beyond-annotation disclosure the 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 sentences, each with a distinct job: purpose, positive trigger, two exclusion routes, and output/injection caveats. Front-loaded purpose, zero 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?

No output schema exists, yet the description explains the empty-result signal and the untrusted-field contract, which is more than most tools in this family. The only real gap is parameter format guidance for site_url and page.

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 two required parameters, so the description carries the burden and largely fails it. Only a weak indirect hint exists — 'which queries one URL ranks for' implies `page` is a URL related to `site_url` — but no formats, accepted forms, or the site_url/page relationship are specified.

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?

States a specific verb and resource with explicit scope: 'List the search queries that sent Bing traffic to one page.' It also names the siblings it is not (bing_traffic_pages, bing_url_info), so an agent can distinguish it from ~50 similarly named traffic tools without opening a 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?

Gives an explicit trigger ('Use when the user asks which queries one URL ranks for') plus two named exclusions pointing to the correct alternative for site-wide page lists and for crawl status. Nothing about selection 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.

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

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is not obligated to restate it. It adds genuinely new behavior: the empty_response label meaning 'silence, not a measurement' and the instruction to treat untrusted fields strictly as data. That is useful edge-case and prompt-injection guidance beyond structured fields, though return shape/pagination is still unstated.

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?

Front-loaded purpose followed by usage, an exclusion with a named alternative, an empty-result edge case, and a security directive. Every sentence earns its place with 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?

No output schema exists, and the description compensates by explaining the empty_response label. For a single-parameter read tool with rich annotations this is nearly sufficient; the missing piece is the site_url input format, which is not fully covered by any source.

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?

One parameter (site_url) at 0% schema description coverage, so the description carries the full burden — yet it never states the expected URL format (scheme, host-only vs. path, whether a domain property or full URL is required). The phrase 'one site' loosely implies the scope but gives no syntax guidance.

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?

States a specific verb and resource ('List the pages on one site that received Bing search traffic') and immediately distinguishes itself from the sibling bing_traffic_page, which covers the queries behind a single page. An agent can route correctly without opening either 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?

Explicit when-to-use ('which pages earn Bing traffic or which URLs lost clicks') plus an explicit when-not with a named alternative ('Do not use this for the queries behind one page; call bing_traffic_page'). 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.

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

Annotations already declare the read-only/idempotent/non-destructive profile, and the description adds behavior the annotations cannot: that an empty result carries an empty_response label meaning 'silence, not a measurement', plus a directive to treat untrusted fields as data only. This is exactly the added-context value the annotations do not supply.

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?

Front-loads purpose before routing and caveats, and every sentence carries distinct information (scope, trigger, exclusion, empty-result semantics, injection safety). It runs slightly long, but no sentence is 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?

With no output schema, the description covers the most important return-shape caveat (empty_response) that an agent would otherwise misreport. The remaining gap is the site_url input contract, which is neither in the schema nor the description.

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