Server Quality Checklist

Tool Scores

• bing_get_url_traffic_infoC
  2.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the read-only nature is covered structurally. The description adds no extra behavioral context beyond what annotations provide — no note about data freshness, rate limits, or whether results include historical/sparkline data.

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

  Conciseness4/5

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

  A single clean, direct sentence with zero filler. Fits the concise ideal, though the brevity comes at the cost of missing contextual guidance.

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

  Completeness2/5

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

  No output schema exists, so the description should explain what traffic details are returned. It doesn't. Given the crowded sibling space with overlapping stats tools, the description is too thin to help an agent select this tool confidently or understand its output.

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

  Parameters3/5

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

  Schema coverage is 100% and both params are well-described ('Exact live page URL', 'Exact verified site URL returned by bing_list_sites'). The schema already does the heavy lifting. The phrase 'for one URL' in the description points to the url param but adds no format or constraint info beyond the schema.

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

  Purpose3/5

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

  States 'Get Bing index traffic details for one URL' — clear verb+resource, and the 'for one URL' distinguishes it from sibling bing_get_children_url_traffic_info. However, it doesn't clarify what specific 'traffic details' are returned (impressions, clicks, position, etc.), nor how it differs from sibling bing_get_url_info, bing_get_page_stats, or bing_get_rank_and_traffic_stats.

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

  Usage Guidelines2/5

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

  No guidance on when to use this vs alternative traffic/rank tools. With siblings like bing_get_rank_and_traffic_stats, bing_get_page_stats, and bing_get_url_info, the description gives no differentiation or selection criteria. Also fails to mention that site_url must be a verified site from bing_list_sites, though that requirement is embedded in the schema.

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

• bing_get_crawl_statsC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds a minor temporal scoping note ('typically covering recent months') but doesn't explain pagination semantics, what happens if the site has no crawl data, or the interpretation of the returned statistics. With thorough annotations, 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.

  Conciseness4/5

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

  One sentence, no filler. It's efficiently written and front-loaded with the core function, though the single sentence is somewhat thin rather than genuinely economical—there was room to add useful context without bloat.

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

  Completeness3/5

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

  For a read-only, idempotent list-type tool with a 100%-covered schema and no output schema, this is roughly adequate. However, given the large sibling set of Bing/SEO tools, the description would benefit from clarifying what specific crawl data it exposes versus crawl issues/sitemaps/fetched URLs, and what the 'rows' of output represent.

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

  Parameters3/5

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

  Schema coverage is 100%, so both parameters (site_url and limit) are described in the input schema. The description adds minimal value beyond schema—it doesn't clarify what 'limit' caps (rows of what exactly?) beyond what schema says. Baseline 3 applies since the schema carries the full documentation burden.

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

  Purpose3/5

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

  The description states the tool gets Bing crawl statistics for a site over recent months, but it's vague about what 'crawl statistics' actually means (pages crawled, crawl frequency, bingbot activity?). It names a resource (Bing crawl stats) and a verb (get) but doesn't differentiate what data it returns compared to sibling tools like bing_get_page_stats, bing_get_fetched_url_details, or bing_get_crawl_issues.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool vs. alternative Bing crawler-related tools (crawl issues, fetched URLs, sitemaps). The description implies a time-bound query ('typically covering recent months') but gives no exclusions or comparisons. The site_url being 'exact verified URL returned by bing_list_sites' hints at a prerequisite but that is in the schema, not the description.

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

• bing_get_keyword_statsC
  2.9/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile well. The description adds that statistics are 'historical' for a 'query, country, and language' scoping, which gives some context beyond annotations. However, it doesn't specify the date range of 'historical' data, how far back it extends, or what statistics exactly are returned (search volume, impressions, clicks, CPC?). The description does not contradict annotations.

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

  Conciseness4/5

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

  A single concise sentence communicating the core purpose efficiently. No wasted words. However, it is minimal enough that some of the gaps in other dimensions stem from its brevity, though brevity alone isn't a flaw.

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

  Completeness2/5

  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 clarify what data is returned. It doesn't specify what 'keyword statistics' include, the historical time range, pagination behavior, or the meaning of the return shape. For a tool with 4 parameters and no output schema, this is incomplete for an agent to predict the tool's behavior reliably.

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

  Parameters2/5

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

  Schema description coverage is only 25%, meaning only 'limit' is documented in the schema. The description mentions query, country, and language but adds no formatting or syntax guidance (e.g., expected country code format like 'US' vs full name, language code like 'en' vs 'English'). With low coverage, the description should have compensated by clarifying parameter formats, and it largely doesn't.

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

  Purpose4/5

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

  The description states 'Get Bing's historical keyword statistics for a query, country, and language' - a clear verb+resource+scoping that conveys it retrieves historical stats filtered by query, country, and language. It distinguishes from siblings like bing_get_query_stats by focusing on keyword-level historical statistics, though it doesn't explicitly differentiate from bing_get_related_keywords or bing_get_query_stats.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus siblings. With ~50 sibling tools including bing_get_query_stats (which could overlap in what stats are returned) and bing_get_related_keywords, the description gives no direction on when a user should choose keyword stats over query stats or related keywords. No prerequisites, exclusions, or alternative recommendations are mentioned.

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

• bing_get_query_statsC
  2.9/5.0
  Behavior2/5

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

  Annotations declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal context beyond the annotations—it doesn't describe time-range scoping, data freshness, pagination behavior, or whether results are aggregated. For a stats-gathering tool, returning results characteristics would be valuable context.

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

  Conciseness4/5

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

  The description is a single efficient sentence with zero filler words. It's appropriately brief for a state-retrieval tool. However, it could add a touch more utility value (e.g., noting the site_url must be a verified site) without becoming bloated.

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

  Completeness3/5

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

  For a straightforward read-only stats tool with full schema coverage and strong annotations, this is largely adequate. The main gap is not explaining what distinguishes 'top queries' (time range default? ranking by clicks?) and not clarifying return value structure, though no output schema exists. It's functional but lean for an SEO data tool.

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

  Parameters3/5

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

  Schema coverage is 100%, so both parameters (site_url, limit) are documented in the schema with descriptions and constraints. The description itself adds no parameter-level meaning. The baseline 3 applies since the schema does the heavy lifting, and the description doesn't distinguish which parameters are critical or explain the relationship between them.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('clicks, impressions, and average positions for top search queries'). It indicates this returns query-level stats. However, it doesn't explicitly differentiate from siblings like bing_get_page_stats or bing_get_keyword_stats, though the title 'Top Bing queries' clarifies the query focus.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus siblings. With many similar bing_get_*_stats tools in the sibling list (page stats, keyword stats, crawl stats, rank/traffic stats), the lack of any when-to-use or comparison guidance leaves the agent to infer which stats tool fits a given need.

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

• bing_get_link_countsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds the notion of 'official Bing result page' and the pagination dimension, but doesn't disclose what the result page contains beyond 'site URLs and their inbound-link counts,' nor whether results are ordered or truncated. With strong annotations covering the safety profile, a 3 is appropriate since the description adds modest value.

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

  Conciseness4/5

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

  Single, efficient sentence with zero waste. It's appropriately brief for a read-only data-fetch tool. Slightly opaque terminology ('official Bing result page') could be clarified, but overall the description is well-sized.

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

  Completeness3/5

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

  For a simple 2-parameter read tool with full schema coverage and strong annotations, the description is close to adequate. However, given the crowded sibling space (many bing_get_* tools), it would benefit from clarifying how its results (inbound link counts per site) differ from bing_get_url_links or bing_get_page_stats, and what pagination via the 'page' parameter implies for the returned data set. Without an output schema, a bit more detail on the result structure would improve completeness.

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

  Parameters3/5

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

  Schema coverage is 100%, so both parameters (page, site_url) are documented in the schema itself. The description adds the 'official Bing result page' framing and links site_url to bing_list_sites output (via schema), but doesn't add meaning beyond the schema's own descriptions. Per the baseline rule for high schema coverage, a 3 is appropriate.

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

  Purpose4/5

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

  The description states the verb+resource: 'Get one official Bing result page of site URLs and their inbound-link counts.' It clearly identifies the tool's function as retrieving a single page of link-count data. However, it doesn't distinguish from sibling tools like bing_get_url_links or bing_get_page_stats, which are close in domain; the scope ('official Bing result page') is stated but sibling differentiation is absent.

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

  Usage Guidelines2/5

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

  No explicit when-to-use guidance is provided. The description doesn't mention when to prefer this over bing_get_url_links, bing_get_page_stats, or other link-related siblings. The site_url parameter note (in schema) references bing_list_sites, but the description itself offers no usage context, prerequisites, or exclusions.

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

• bing_get_page_statsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well established. The description adds minimal behavioral context beyond that. It doesn't explain what 'top' means, whether results are sorted, pagination behavior, or time-window semantics. With strong annotations, a 3 is appropriate as the description is non-contradictory but adds little.

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

  Conciseness4/5

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

  The description is a single efficient sentence that lists what data is returned. It is front-loaded and incurs zero waste. While extremely brief, it conveys the core purpose without unnecessary elaboration. One could argue for a 5, but the lack of any usage distinction makes it slightly less complete as a standalone text.

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

  Completeness3/5

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

  For a read-only page-stats retrieval tool with 100% schema coverage, strong annotations, and no output schema, the description is minimally adequate. It tells the agent what data will be returned (clicks, impressions, avg position) but is ambiguous about 'top pages' criteria and leaves the agent guessing about ordering and time windows. Given the large sibling set with similar page/query stats tools, more differentiation would improve completeness.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters (site_url and limit) are documented in the schema. The description does not add parameter-level meaning beyond what's in the schema. site_url's requirement that it be an 'exact verified site URL returned by bing_list_sites' is well documented in the schema itself. Baseline 3 is correct when the schema carries the full load.

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

  Purpose4/5

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

  The description clearly states the verb + resource: 'Get clicks, impressions, and average positions for top pages.' It communicates what data is retrieved (per-page metrics) and is reasonably distinguishable from siblings like bing_get_keyword_stats and bing_get_crawl_stats. However, it doesn't explicitly contrast against sibling tools like bing_get_query_page_stats or bing_get_url_traffic_info, which could be easily confused for similar page-level metrics.

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

  Usage Guidelines2/5

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

  There is no explicit when-to-use guidance or exclusions. The description implies it reports top performing pages, but doesn't tell the agent when to choose this vs bing_get_page_query_stats, bing_get_url_traffic_info, or bing_get_rank_and_traffic_stats. No alternative tools are named, and no context about 'top' definition (recency, date range) is provided.

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

• bing_get_related_keywordsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile well. The description adds that it's limited to what 'Bing's API supports,' which implies some API constraints but doesn't detail pagination, rate limits, or whether results vary over time. With strong annotations, this is acceptable.

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

  Conciseness4/5

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

  Single sentence, no wasted words, front-loads the core function. It efficiently captures the tool's essence without filler. Could arguably mention parameter formats, but for length it's appropriately concise.

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

  Completeness3/5

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

  This is a reasonably simple filtered-lookup read tool with strong annotations covering the safety profile. However, with 5 of 6 parameters undocumented in the schema (17% coverage), and no output schema, the description should provide more guidance on expected value formats (country, language codes, date conventions) and result semantics to be fully complete.

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

  Parameters2/5

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

  Schema description coverage is only 17% — the schema provides no descriptions for query, country, language, start_date, or end_date beyond format constraints. The description name-drops all five parameters but adds no semantics about formats (e.g., is 'country' a code like 'US' or a name?), date range constraints (max span?), or expected value formats. It lists the parameters but doesn't explain how to populate them correctly.

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

  Purpose4/5

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

  The description states a specific verb+resource ('Get related-keyword impressions') with explicit scoping to query, country, language, and date range. It doesn't explicitly distinguish from siblings like bing_get_keyword_stats, but the 'related-keyword' focus is reasonably clear given the name and title already convey the purpose.

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

  Usage Guidelines3/5

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

  The description says it gets impressions 'supported by Bing's API' which implies API limitations but doesn't give explicit when-to-use vs alternatives. It doesn't mention that siblings like bing_get_keyword_stats or bing_get_query_stats might be more appropriate for other keyword analysis needs. No exclusions or alternatives named.

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

• bing_get_rank_and_traffic_statsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds nothing beyond stating it returns overall stats. It doesn't disclose aggregation scope, time window, or what rank/traffic metrics are included, which is a modest gap but not a contradiction.

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

  Conciseness4/5

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

  The single-sentence description is efficient and front-loaded with the action. No wasted words. It's appropriately minimal for what it conveys, though it could add a touch more behavioral detail without harming conciseness.

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

  Completeness3/5

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

  For a read-only stats tool with strong annotations, schema coverage of 100%, and no output schema, the description is minimally viable. However, 'rank and traffic statistics' is vague—it doesn't specify what rank metrics (delta vs absolute), time range, or traffic units are returned. Given the tool's site-level scope and the sibling ecosystem's specificity, slightly richer context would help.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters (site_url and limit) are already documented in the schema. The description adds no parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('overall Bing rank and traffic statistics') for a verified site. It distinguishes reasonably from siblings like bing_get_query_stats and bing_get_page_stats by indicating it's site-level overall stats, though it could be more explicit about the site-level scope (vs per-query/per-page ranks).

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

  Usage Guidelines3/5

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

  The description and schema imply this is for overall site stats once a site is verified, but there's no explicit when-to-use vs alternatives guidance. Siblings like bing_get_query_stats (per-query) and bing_get_page_stats (per-page) suggest alternatives exist but aren't mentioned. The schema notes site_url must come from bing_list_sites, which is a useful contextual hint.

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

• bing_submit_sitemapB
  3.4/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds little behavioral context beyond 'Submit'. For a mutating submit action with open-world semantics (external service call), one might expect disclosure about submission limits, quota consequences, or confirmation behavior, but the description stays minimal. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is a single efficient sentence with zero waste. Title and description align. Could arguably be more informative, but the structure is clean and front-loaded.

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

  Completeness3/5

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

  This is a simple two-parameter submit tool with 100% schema coverage, so the bar for description completeness is moderate. However, with openWorldHint=true and idempotentHint=false (a non-idempotent mutation), some disclosure about what happens on repeated submissions, quotas, or feedback would strengthen completeness. The input-side is well covered but behavioral implications are not addressed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no additional nuance beyond what the schema provides (e.g., no format requirements for sitemap_url, no note about feed vs sitemap differences, no validation constraints). Baseline 3 is appropriate given full schema coverage.

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

  Purpose4/5

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

  The description states the action clearly with specific verb and resource: 'Submit a sitemap or feed URL to Bing Webmaster.' It distinguishes the tool from siblings like bing_submit_url (which submits individual URLs) and bing_get_sitemaps (which reads sitemaps). However, it doesn't explicitly name these alternatives for differentiation.

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

  Usage Guidelines3/5

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

  The schema's site_url parameter references bing_list_sites ('Exact verified site URL returned by bing_list_sites'), which serves as an implicit prerequisite hint. However, the description itself provides no when-to-use guidance, no indication of when this applies vs the indexnow_submit_url tools, and no explicit mention of the required verification prerequisite.

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

• indexnow_submit_urlB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so mutation is implied. The description adds useful caveats: it validates the same-host key file and explicitly states it does not guarantee crawling or indexing. However, with a mutation tool, it doesn't disclose side effects like rate limits, quota impact, or failure behavior beyond the key validation step.

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

  Conciseness4/5

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

  The description is two sentences with zero waste. It front-loads the primary action and caveat efficiently. However, it is slightly under-specified for the number of parameters and sibling tools; nominal structure is good.

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

  Completeness3/5

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

  With 3 parameters, no output schema, and moderate annotations, the description covers the core action and one key caveat (no crawl guarantee). But for a mutation tool among many submit variants, it leaves ambiguity about prerequisites (key validation flow), quota implications, and what success looks like (no output schema to define). Acceptable but not complete.

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

  Parameters3/5

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

  Schema description coverage is only 33% (only site_url has a description, referencing bing_list_sites). The description adds the distinction that url must be 'public' and the change_type values are implicitly enumerated in the description text ('added, updated, or deleted'). It adds some meaning but doesn't clarify the url format expectations or how change_type affects behavior beyond echoing the enum.

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

  Purpose4/5

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

  The description clearly states the action: 'Validate the same-host key file and notify IndexNow about one added, updated, or deleted public URL.' It names a specific verb+resource (notify IndexNow) and lists the URL statuses. However, it doesn't explicitly distinguish from sibling indexnow_submit_urls (batch version) beyond the implied 'one' vs plural, which is a minor gap.

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

  Usage Guidelines3/5

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

  The description implies usage by listing the URL statuses (added/updated/deleted) and states it doesn't guarantee crawling or indexing, which sets expectations. However, there are many sibling submission tools (bing_submit_url, bing_submit_url_batch, bing_submit_sitemap, indexnow_submit_urls, indexnow_validate_key) with no explicit when-to-use-this-vs-alternatives guidance, and no relation to the prerequisite bing_list_sites/validate_key flow is stated.

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

• aeo_ai_readability_auditA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the specific behavioral criteria that will be checked, which is genuinely useful context. It doesn't describe return format or scoring methodology, but with strong annotations the burden is lower.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the five key criteria. No filler or redundancy. It could arguably be slightly more compact, but it earns each clause by enumerating the audit dimensions.

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

  Completeness4/5

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

  For a single-parameter read-only audit tool with no output schema, the description adequately conveys what will be assessed. The five enumerated criteria give the agent a good sense of expected outputs. It doesn't explain scoring/return format, but the criteria list is reasonably complete for guiding invocation.

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

  Parameters3/5

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

  Schema coverage is 100% with a single parameter (url) fully described as 'Public webpage URL'. The description adds no additional parameter meaning, but with only one parameter at full schema coverage, there is nothing meaningful to add. The baseline of 3 applies exactly here.

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

  Purpose4/5

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

  The description clearly states it checks a page's readability/AI-readiness across five concrete dimensions (focused answer, definition, heading structure, readable sections, marketing restraint). The verb 'check' plus the list of criteria makes the purpose clear. It doesn't name a sibling alternative, but it's distinguishable from the other many 'aeo_' audit tools by its specific readability focus.

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

  Usage Guidelines3/5

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

  The description implies usage for evaluating whether a page is AI/readability-friendly, but gives no explicit when-to-use guidance or exclusions versus the many sibling audit tools (aeo_audit_page, aeo_intent_coverage, aeo_entity_coverage, etc.). It doesn't name alternatives or when-not-to-use, though the focused criteria provide implicit context.

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

• bing_get_query_page_detail_statsA
  3.5/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile well. The description adds 'dated' (implying time-series) but doesn't disclose pagination behavior, default limit semantics, or what happens when data exceeds the limit. Given the strong annotations coverage, a 3 is appropriate — the description adds modest value but doesn't detail return shape or ordering.

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

  Conciseness5/5

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

  A single, dense sentence conveys the complete purpose with zero waste. The description front-loads the verbs and resource clearly and contains no redundant or filler content.

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

  Completeness3/5

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

  For a moderate-complexity read tool with good annotations and a 4-parameter schema at 50% coverage, the description is adequate but sparse. It doesn't explain what 'position' means, how rows are ordered, default behavior when limit is exceeded, or the relationship between query and page_url. There's no output schema, so the description could reasonably note what data shape to expect, but this is not a critical gap given the annotations.

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

  Parameters3/5

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

  Schema coverage is 50%: site_url and limit have descriptions, but query and page_url lack them. The description mentions 'dated' metrics which clarifies what the returned rows represent but doesn't explain the relationship among site_url/query/page_url parameters or how they combine (e.g., whether page_url must belong to site_url). The limit parameter's semantic is already in schema, so the description adds minimal parameter value beyond the schema.

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

  Purpose4/5

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

  The description 'Get dated clicks, impressions, and position details for one query and one page' uses a specific verb (get) with a clear resource (dated performance metrics) scoped to one query and one page. It distinguishes reasonably from siblings like bing_get_query_stats (query-level) and bing_get_page_stats (page-level) by specifying the query+page combination, though it doesn't explicitly name those alternatives.

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

  Usage Guidelines3/5

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

  The description implies usage for single query+page granularity, distinguishing from broad query or page stats siblings. However, it doesn't explicitly state when to use this versus bing_get_query_stats, bing_get_page_stats, or the very similar bing_get_query_page_stats sibling, nor does it state when NOT to use it (e.g., for multi-query or multi-page needs).

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

• bing_get_query_page_statsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds minimal behavioral context beyond what annotations provide. It doesn't disclose return format, pagination, or any quirks about how stats are computed. With strong annotation coverage, the bar is low, and the description doesn't contradict or meaningfully extend 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.

  Conciseness5/5

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

  The description is a single, concise sentence with zero wasted words. It front-loads the key action ('Get') and resource ('Bing traffic statistics for pages'). No redundant qualifiers or fluff.

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

  Completeness3/5

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

  For a read-only stats retrieval tool with good annotations (readOnlyHint, openWorldHint, idempotentHint) and a moderately documented schema, the description is adequate. No output schema exists, so the description could arguably mention the shape of returned stats, and the query param lacks description. The tool is relatively simple with only 2 required params, so the minimal description is mostly sufficient, though it could clarify the distinction from the similarly-named bing_get_query_page_detail_stats sibling.

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

  Parameters3/5

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

  Schema description coverage is 67% - site_url and limit have descriptions, but query does not. The description adds the notion that stats are 'for pages associated with one search query,' which clarifies what query means contextually. However, it doesn't elaborate on what 'traffic statistics' includes as fields, or the relationship between site_url and query. With 67% coverage, schema does most of the work, and the description contributes modest context but doesn't fully fill the gap for the undocumented query parameter.

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

  Purpose4/5

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

  The description 'Get Bing traffic statistics for pages associated with one search query' clearly states the action (get stats) and the resource (Bing pages associated with a query). It distinguishes from siblings like bing_get_page_stats (single page) and bing_get_query_stats (query-level stats) by clarifying it returns pages associated with a single query. However, it doesn't explicitly differentiate from bing_get_query_page_detail_stats, which appears closely related.

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

  Usage Guidelines3/5

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

  The description implies usage context: it's for getting per-page stats for a single query. However, it doesn't explicitly state when to use this tool vs alternatives like bing_get_query_stats or bing_get_query_page_detail_stats. The site_url parameter description in the schema ('Exact verified site URL returned by bing_list_sites') provides some prerequisite guidance, but the overall when-vs-alternatives guidance is implied rather than explicit.

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

• bing_get_sitemapsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint true and destructiveHint false, so the safety profile is fully covered by annotations. The description adds the fact that it reports on sitemap AND feed status, which is a worthwhile behavioral detail, but it doesn't disclose pagination behavior, response format, or latency characteristics.

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

  Conciseness5/5

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

  A single, clear sentence that states purpose without padding. Every word earns its place, and the description is appropriately front-loaded with the action verb.

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

  Completeness3/5

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

  For a simple read-only reporting tool with 2 well-documented parameters, full annotations, and no output schema, the description is nearly complete. It could add context about what a 'feed' is or the distinction between sitemap and feed results, but given the strong schema and annotation coverage, this is adequate for the tool's complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters fully documented (site_url as 'exact verified site URL returned by bing_list_sites' and limit with min/max/default). The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  Uses a specific verb+resource ('Get submitted sitemap and feed status') and clearly identifies what data it returns. While it distinguishes from bing_submit_sitemap (which submits), it doesn't explicitly differentiate itself among the many bing_get_* reporting siblings, all of which follow the same 'get status from Bing Webmaster' pattern.

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

  Usage Guidelines3/5

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

  The description implies a read-only query context but provides no explicit when-to-use or when-not-to-use guidance. The schema's site_url parameter description references bing_list_sites as a prerequisite dependency, which offers indirect usage clues, but the description itself doesn't mention that dependency or exclude alternatives.

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

• aeo_extract_citable_chunksA
  3.6/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so this is a safe read/idempotent operation. The description adds a valuable behavioral note: the output includes a 'transparent heuristic score' explaining why each chunk was selected, which goes beyond what a simple 'extract chunks' tool would imply. This transparency about the scoring mechanism is genuinely useful context not present in annotations.

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

  Conciseness5/5

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

  A single, efficient sentence that conveys the core purpose and the key output behavior (transparent heuristic scores). Zero wasted words, front-loaded with the action verb. No filler or redundancy.

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

  Completeness4/5

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

  For a read-only, idempotent extraction tool with only 2 parameters and no output schema or nested objects, the description covers the essential behavior: what it extracts and that it provides transparent scoring. The main gap is the undocumented limit parameter's semantics, but given the tool's simplicity and strong annotation coverage (safe, read-only, idempotent), the description is reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 50%: the url parameter has a description ('Public webpage URL') but limit has only a default value with no description text. The description adds minimal parameter meaning—no mention of what limit controls (number of chunks returned) or how it interacts with the scoring threshold. Baseline 3 applies given partial coverage, but the description doesn't compensate for the undocumented limit parameter.

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

  Purpose4/5

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

  The description uses a specific verb ('Find') and resource ('concise standalone definitions and factual passages on a page'), clearly stating what the tool extracts. It doesn't explicitly differentiate from siblings, but the AEO sibling family is large; while the 'citable chunks' concept is fairly unique among them, the description doesn't name an alternative. Still clear enough for primary purpose.

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

  Usage Guidelines2/5

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

  No explicit when-to-use or when-not-to-use guidance is given. The description mentions it explains a 'transparent heuristic score' which hints at its distinguishing feature, but it never tells the user when to prefer this over similar AEO tools like aeo_citation_readiness or aeo_ai_readability_audit. Context must be inferred entirely from the tool name and description.

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

• aeo_multilang_schema_parityA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation. The description adds the freshness comparison aspect and @graph markup support, which is some additional context, but doesn't describe output format or how contrasts are reported. With strong annotations covering the safety profile, a 3 is reasonable.

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

  Conciseness4/5

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

  Two sentences, no wasted words. The first sentence is front-loaded with the core action and scope; the second adds a useful compatibility note about @graph markup. Slightly more behavioral detail could be added without being verbose.

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

  Completeness4/5

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

  For a read-only analysis tool with no output schema and rich annotations, the description adequately covers purpose, inputs (via schema), and supported markup. The single parameter is fully documented in the schema. The main gap is not describing what the comparison output looks like, but for a non-mutating analysis tool with full annotation coverage, this is acceptable.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the schema already documents the single 'pages' parameter well (array, 2-20 items, each with locale and url). The description adds value by explaining what the tool does with those pages (compares schema and freshness), going beyond the raw schema definitions. With a single well-documented parameter, the description's conceptual framing is sufficient.

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

  Purpose4/5

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

  The description clearly states the verb ('Compare'), the resources (Article and FAQPage JSON-LD plus dateModified freshness), and the scope (across translated versions of the same article). It distinguishes itself from siblings by being specific about multilingual schema/freshness parity, though it doesn't explicitly name a differentiating sibling tool. The 'Supports common @graph markup' note adds useful specificity.

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

  Usage Guidelines3/5

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

  The description implies usage context (comparing multilingual article versions for schema/freshness parity) but doesn't explicitly state when to use this versus alternatives or when not to use it. It doesn't mention exclusions or alternatives. The '2 to 20 translated versions' constraint is helpful context for when this tool applies.

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

• bing_get_children_url_traffic_infoA
  3.6/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, which already cover the safety profile. The description adds the 'one official Bing result page' limitation, which is genuinely useful context since openWorldHint might suggest completeness. However, it doesn't explain that only one page is returned or how page/limit interplay works behaviorally.

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

  Conciseness5/5

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

  Single sentence, zero wasted words. Front-loaded with the key distinguishing detail ('index traffic details for URLs under a directory'). Example of efficient specification.

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

  Completeness4/5

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

  For a read-only data retrieval tool with 100% schema coverage, clear annotations, and no output schema, the description provides the essential scoping information (directory-level query) that the agent needs. The only minor gap is not stating that only one page is returned despite the pagination parameters, but the schema's 'Zero-based API result page' partially covers this. Adequate for the tool's complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 4 parameters are documented in the schema (url, page, limit, site_url). The description adds minimal new meaning beyond the schema — it clarifies that 'url' is a directory and 'site_url' must be verified via bing_list_sites (which is in the schema description). Baseline 3 is appropriate given the schema carries the heavy lifting.

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

  Purpose4/5

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

  The description states the verb ('get'), resource ('Bing result page of index traffic details'), and scope ('URLs under a directory'), which clearly differentiates from siblings like bing_get_url_traffic_info (single URL) and bing_get_rank_and_traffic_stats. It's specific enough to establish purpose, though it doesn't explicitly contrast with the sibling tools.

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

  Usage Guidelines3/5

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

  The word 'official' and 'one...page' imply a single page fetchet rather than exhaustive pagination, and 'under a directory' clarifies scope. However, it doesn't explicitly say when to prefer this over bing_get_url_traffic_info or bing_get_page_stats, and doesn't describe exclusions or alternatives. Usage context is implied rather than stated outright.

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

• bing_get_crawl_issuesA
  3.6/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered structurally. The description adds little behavioral context beyond what annotations provide, but it doesn't contradict them. No mention of pagination/defaults or result format, though the limit param hints at it.

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

  Conciseness5/5

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

  A single sentence, zero filler, perfectly concise. No wasted words while still conveying the core function clearly.

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

  Completeness4/5

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

  For a read-only filtered-list tool with full schema parameter coverage and safety annotations, the description is adequate. It doesn't explain result semantics (what kinds of crawl problems are returned), but for a simple retrieval tool with annotations and schema doing the heavy lifting, this is reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both params (site_url, limit) are already documented in the schema. The description adds no additional parameter meaning beyond what the schema provides, which places it at the baseline 3 for full coverage.

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

  Purpose4/5

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

  "Get crawling problems Bing has found for the site" is a clear verb+resource combination indicating the tool retrieves crawl issues for a given site. It distinguishes reasonably from siblings like bing_get_crawl_stats and bing_get_sitemaps by referencing 'problems', though it doesn't explicitly contrast with those siblings.

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

  Usage Guidelines3/5

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

  The description implies usage (getting crawl issues for a site) but provides no when-to-use vs alternative tools, no prerequisites beyond the site_url param, and no exclusions. The schema references bing_list_sites for the site_url value, which is a helpful cross-reference, but the description itself carries no usage direction.

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

• bing_get_page_query_statsA
  3.6/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, which fully cover the safety profile. The description adds no additional behavioral context beyond that, such as how results are ordered, whether pagination is needed, or what the limit parameter does. With strong annotations, the bar is lower, and the description contributes marginal but non-zero value.

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

  Conciseness4/5

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

  A single concise sentence that is efficient and front-loaded with the core purpose. No wasted words. However, it could add a small bit of differentiating context without becoming verbose.

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

  Completeness3/5

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

  No output schema exists, so the description carries the burden of explaining what results look like, but it doesn't describe the return format. For a read-only query-stats tool with good annotations and 100% schema coverage, this is a modest gap. It's a simple enough tool that this functionality is largely adequate.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all three parameters (site_url, page_url, limit) are already documented in the schema. The description itself doesn't add semantic depth beyond the schema, such as explaining that site_url must come from bing_list_sites or how limit interacts with result volume. Baseline 3 applies as schema does the heavy lifting.

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

  Purpose5/5

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

  The description 'Get search-query statistics for one specific page' has a specific verb (get), resource (search-query statistics), and scope (one specific page). It clearly distinguishes from sibling tools like bing_get_query_stats (which likely covers all pages) and bing_get_page_stats (which likely gives page stats not query-specific). The 'one specific page' language sharpens the differentiation.

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

  Usage Guidelines3/5

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

  The description implies the tool takes a single page and returns query stats, but doesn't explicitly contrast with bing_get_query_page_stats (which may return query-page combos) or bing_get_page_stats. It doesn't state when to use this over the many sibling query/page tools. Clear context but no exclusions or explicit alternates named.

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

• bing_get_url_infoA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile well. The description adds the 'only fields returned by the official GetUrlInfo method' caveat, which is useful for setting expectations about scope. However, it doesn't describe what fields are actually returned, freshness expectations, or how to handle pages not in the index, though the lower bar due to strong annotations keeps this at a 3.

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

  Conciseness4/5

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

  The description is a single efficient sentence with no waste. It's front-loaded with the verb and resource. It could arguably add a touch more guidance without bloating, but as written it's appropriately sized and direct.

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

  Completeness3/5

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

  There's no output schema, so the description should ideally hint at what 'index details' means. With no output schema and several sibling tools that return different URL-related data, the description could better clarify what distinguishes these index details from traffic stats or fetched URL details. However, for a read-only single-page lookup with strong annotations and 100% param coverage, it's reasonably complete, though slightly under-specified given the absence of an output schema.

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

  Parameters3/5

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

  Schema coverage is 100%, with both parameters (url and site_url) already described in the schema. The description adds no param-level detail beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting and both required params are self-explanatory.

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

  Purpose5/5

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

  The description clearly states the tool gets Bing's index details for one page, with a specific verb ('Get'), resource ('Bing's index details for one page'), and scope ('for one page' and 'only fields returned by the official GetUrlInfo method'). It distinguishes from siblings like bing_get_url_traffic_info and bing_list_sites by focusing on index details vs traffic or site listing.

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

  Usage Guidelines3/5

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

  The description implies this is for a single page (contrasting with list/summary siblings), and the phrase 'only fields returned by the official method' gives some scope clarity. However, it doesn't explicitly state when to use this versus bing_get_fetched_url_details, bing_get_url_traffic_info, or other URL-detail siblings, nor does it name alternatives. Context is implied but not explicit.

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

• bing_get_url_linksA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds value by clarifying this returns a single 'official Bing result page' (implying one page of results, not all), and that site_url must be a verified exact match from bing_list_sites (visible in schema). No contradiction with annotations.

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

  Conciseness4/5

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

  Single sentence, zero waste, front-loaded with the key action. It's appropriately short for a tool whose parameters are fully documented in the schema.

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

  Completeness3/5

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

  For a read-only listing tool with no output schema and full schema parameter coverage, the description is reasonably complete. However, it doesn't detail what the returned page contains beyond 'inbound links and anchor text' (e.g., format, pagination behavior, rate limits), and doesn't distinguish against bing_get_link_counts which might also relate to links. With no output schema, a bit more on the return format would help.

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

  Parameters3/5

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

  Schema description coverage is 100% (all 3 parameters have descriptions in the schema). The description adds context by noting it returns 'one official Bing result page' implying pagination via the page parameter, and the verified site_url requirement ties into the schema's 'Exact verified site URL returned by bing_list_sites' note. Baseline 3 is appropriate since schema carries the parameter documentation.

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

  Purpose4/5

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

  The description clearly states the verb (get), resource (Bing inbound links and anchor text), and scope (one official result page for a site URL). It distinguishes itself from sibling tools like bing_get_link_counts (which returns counts) and bing_get_url_info by specifying it returns inbound links with anchor text.

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

  Usage Guidelines3/5

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

  The description implies usage context via 'official Bing result page' and 'inbound links and anchor text', but does not explicitly state when to use this tool versus siblings like bing_get_link_counts or bing_get_url_info. There is no explicit when/when-not guidance or alternative naming.

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

• bing_list_sitesA
  3.6/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which already cover the safety profile well. The description adds one useful behavioral detail: 'Verification codes are removed from the result,' which discloses a data transformation. This adds value beyond the annotations, though it doesn't describe return format or potential pagination.

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

  Conciseness4/5

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

  Two short sentences, no filler. The behavioral note about verification codes is the only extra detail and it earns its place. Could arguably add more context about what 'sites' means, but it's efficiently written.

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

  Completeness4/5

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

  For a zero-parameter, read-only discovery tool with strong annotations (readOnlyHint, idempotentHint, openWorldHint all true), the description is reasonably complete. The verification-code removal note adds practical value. No output schema exists, so a bit of return-format detail could have helped, but the tool is simple enough that this is adequate.

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

  Parameters4/5

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

  There are 0 parameters, so the baseline for parameter semantics is 4 per the rubric. The description adds the contextual note about verification codes being stripped, which is useful for interpreting results even though no parameters exist.

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

  Purpose4/5

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

  The description clearly states the verb ('List') and resource ('sites available to the connected Bing Webmaster account'), distinguishing it from the many sibling tools that fetch stats, crawl issues, or sitemaps. It's not fully distinguished from every sibling but clearly identifies its scope as listing available sites, not querying metrics.

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

  Usage Guidelines3/5

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

  The purpose is self-evident given the tool name and siblings, but there's no explicit guidance on when to use this vs alternatives. However, since it's a zero-parameter discovery/list tool, the usage context is fairly unambiguous compared to the stat-focused siblings.

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

• seo_recheck_pageA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the workflow context (checking whether fixes worked) but doesn't disclose details like rate limiting, refresh delay between scans, or whether results are cached. For a read-only tool with full annotation coverage, a 3 is appropriate — adds some value but not deep behavioral detail.

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

  Conciseness5/5

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

  A single compact sentence that packs in the action (rescan), scope (one live page), context (after WordPress or code fix), and output expectation (report whether issue codes are gone). Zero waste, no filler, front-loaded with the essential purpose. Ideal length.

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

  Completeness4/5

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

  For a 2-param, read-only tool with full schema coverage and clear annotations, this description is largely adequate. It captures the workflow context (rechecking after fixes) and expected behavior (verifying specific issues are resolved). One minor gap: it doesn't clarify whether rechecking is immediate or subject to indexing/caching delays, but given the simplicity of the tool, this is acceptable.

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

  Parameters3/5

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

  Schema coverage is 100% — both url and expected_fixed_issue_codes have descriptions in the schema. The description mentions 'specified issue codes' linking to the expected_fixed_issue_codes parameter and 'one live page' linking to url, reinforcing the schema. It doesn't add format or constraint details beyond schema, but with full coverage, baseline 3 is correct.

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

  Purpose4/5

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

  The description clearly states the verb+resource: 'Rescan one live page' after a 'WordPress or code fix' and report whether 'specified issue codes are gone'. It distinguishes from sibling tools like seo_scan_page (initial scan) and seo_scan_pages (batch scan) by the 'recheck after fix' framing. Could be slightly more explicit about how it differs from seo_scan_page, but the purpose is clear.

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

  Usage Guidelines3/5

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

  The description implies this is used after making fixes ('after a WordPress or code fix'), which signals the appropriate time to use it. However, it doesn't explicitly name alternatives or state when NOT to use it (e.g., for initial scanning use seo_scan_page, for batch scans use seo_scan_pages). The 'rescan after fixes' context gives reasonable guidance but lacks explicit exclusions.

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

• seo_scan_pagesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which fully cover the safety and side-effect profile. The description adds the 'independently' qualifier (scan is autonomous, not dependent on prior actions) and clarifies return format (affected URLs with issue codes and evidence). It does not describe potential rate limits or failure behavior for inaccessible pages.

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

  Conciseness5/5

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

  A single, compact sentence with zero wasted words. It captures the action, the scope limit, the input requirement (public, live), and the output format in one breath. The title also reinforces the purpose. This is appropriately front-loaded and efficient.

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

  Completeness4/5

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

  Given the tool has only one parameter, full schema coverage, and comprehensive annotations (read-only, idempotent, non-destructive), the description is adequate. It specifies the return format (URLs with issue codes and evidence), which is useful despite the lack of an output schema. The main gap is the lack of differentiation from the singular seo_scan_page sibling, but for a bulk-scan tool with these annotations, the description covers the essentials.

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

  Parameters3/5

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

  Schema description coverage is 100%, with a single 'urls' parameter already described as 'One to 20 public webpage URLs'. The description adds that URLs must be public and live ('live webpages' in title, 'public webpages' in body), which provides slight marginal value beyond the schema. However, it doesn't specify URL format requirements or whether mixed valid/invalid URLs are tolerated.

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

  Purpose4/5

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

  The description clearly states it scans webpages for SEO issues and returns affected URLs with issue codes and evidence. The verb 'scan' plus resource 'webpages' is specific. However, it doesn't distinguish itself from the sibling tool 'seo_scan_page' (singular), and the distinction between single-page and multi-page scanning is only implied through the max 20 limit in the schema, not explicit in the description.

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

  Usage Guidelines3/5

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

  The description notes it scans 'public' webpages and imposes an upper bound of 20 pages. However, it does not explain when to use this multi-page tool versus the singular 'seo_scan_page' or 'seo_recheck_page' siblings. No exclusions or relative guidance (e.g., use this for bulk checks, use singular for a single URL) is provided, so the agent must infer the appropriate usage context.

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

• aeo_entity_coverageA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well established. The description adds meaningful value beyond annotations: it explicitly discloses that the tool performs heuristic detection and deliberately avoids inventing missing entities — useful behavioral transparency about the heuristic/abstention behavior that 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.

  Conciseness4/5

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

  The description is a single concise sentence that delivers the core purpose plus the heuristic-detection differentiator. No fluff or redundant phrasing. It could slightly improve by front-loading the noun/verb structure more explicitly, but it is efficient and earns its place.

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

  Completeness4/5

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

  For a read-only audit tool with strong annotations (safety profile fully covered) and no output schema, the description covers the core behavior: checking primary/related entities, returning heuristic detections, and warning against invented entities. Given there's no output schema to explain return format, the description could describe what the audit output contains, but the core usage contract is adequately specified for a moderate-complexity tool.

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

  Parameters3/5

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

  Schema description coverage is only 33% (only 'url' has documentation), leaving primary_entity and related_entities undocumented in the schema. However, the description partially compensates by clarifying that related_entities is an explicit list checked against the page. It doesn't add richer detail about entity format, how primary vs. related entities are treated differently, or what the returned detected entities look like.

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

  Purpose4/5

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

  The description clearly states the verb (check/audit) and resource (primary entity + related entities against a page), and distinguishes the tool's value by noting it returns 'heuristically detected entities without inventing missing ones.' It identifies what it does and its key differentiator, though it doesn't explicitly distinguish from specific sibling tools like aeo_intent_coverage.

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

  Usage Guidelines3/5

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

  The description implies usage context (auditing a page's entity coverage) but provides no explicit when-to-use guidance or exclusions. It doesn't name alternative tools or state when NOT to use this tool versus siblings like aeo_intent_coverage or aeo_audit_page. Some guidance is implied by the tool's naming and position among aeo_* siblings, but no explicit direction is given.

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

• aeo_intent_coverageA
  3.7/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the value of stating what it reports (missing expected intents), which clarifies the assessment behavior. It doesn't mention output format, but with robust annotations this is acceptable.

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

  Conciseness4/5

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

  A single, dense sentence that enumerates all six intents and states the gap-reporting behavior. No wasted words, though it could be slightly reorganized to front-load the purpose more clearly.

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

  Completeness4/5

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

  For an analysis tool with strong annotations (readOnly, idempotent), the description plus schema is reasonably complete. The six intent types offer clear scope, and sibling tools provide broader context about where this audit fits. Absence of an output schema shifts some burden to the description, but the tool's gap-reporting nature is communicated. No descriptions for sibling tools, so usage differentiation is limited.

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

  Parameters3/5

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

  Schema description coverage is 50%: the 'url' parameter is described as 'Public webpage URL' in the schema, while 'expected_intents' has no schema description. The description's list of six intent types effectively documents the valid values for expected_intents, compensating somewhat for the schema gap. However, it doesn't clarify whether expected_intents is used as a filter/output list or as a required checklist.

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

  Purpose4/5

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

  The description states the verb 'detect' and resource 'intent signals', enumerating six specific intent types and explicitly reporting missing expected intents. This distinguishes it from other aeo_* audit tools, though it doesn't name sibling alternatives explicitly.

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

  Usage Guidelines3/5

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

  The description implies it should be used to analyze a page's intent coverage, and the 'report any expected intents that are missing' phrasing clarifies its role as a gap analyzer. However, it doesn't explicitly state when to use vs alternatives like aeo_entity_coverage or aeo_audit_page, nor when not to use it.

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

• aeo_citation_readinessA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds the valuable caveat that this is 'not a citation guarantee,' which manages agent expectations about what the score means. Given the strong annotation coverage and this added interpretive context, a 4 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.

  Conciseness5/5

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

  The description is two sentences with zero waste. The first sentence defines the tool's output function, and the second provides an important boundary clarification. Every word earns its place; nothing is redundant.

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

  Completeness4/5

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

  This is a single-parameter, read-only tool with strong annotation coverage (readOnly, idempotent, non-destructive) and a fully documented schema. The description adequately covers the scoring intent and the important caveat about citation guarantee. With no output schema and minimal complexity, the description is complete enough for an agent to select and invoke it correctly.

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

  Parameters3/5

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

  There is only one parameter (url) with 100% schema description coverage ('Public webpage URL'). The schema fully documents the only parameter, so the description need not add parameter details. Baseline 3 is appropriate given the schema handles the complete parameter documentation with no gaps.

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

  Purpose4/5

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

  The description uses a specific action verb ('Score') and identifies the resource/domain (whether the page contains concise, structured, well-supported passages easy to extract). It clearly distinguishes itself as an assessment/audit function rather than a citation guarantee, and the tool name 'aeo_citation_readiness' aligns with the described purpose. However, it doesn't explicitly name sibling tools to differentiate from, and the scope is somewhat narrow.

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

  Usage Guidelines3/5

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

  The description explains the tool scores a page's citation-readiness, and the final sentence ('This is not a citation guarantee') sets an expectation boundary. However, it doesn't explicitly state when to use this versus alternatives like aeo_extract_citable_chunks or aeo_ai_readability_audit, nor provide when-not-to-use guidance. The negative clarification is helpful but limited.

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

• aeo_freshness_auditA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds value by disclosing that it flags content for 'human verification' and explicitly that it does not declare content incorrect—a non-obvious behavioral boundary. This is useful but modest extra disclosure beyond annotations.

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

  Conciseness5/5

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

  Two crisp sentences, zero filler. Both sentences add distinct value: the first enumerates what gets flagged, the second explicitly clarifies a limitation. Front-loaded and efficient.

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

  Completeness4/5

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

  The tool has no output schema, so the description bears some responsibility for explaining results. It clarifies the output is a set of flags for human review, not judgments—good. With two simple params (one required URI), generous annotations (readOnly, idempotent, openWorld), and a clear scope, the description is largely sufficient. A minor gap is the lack of explicit mention of the current_year param's role, but overall completeness is strong.

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

  Parameters3/5

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

  Schema description coverage is 50%: the url param is documented ('Public webpage URL'), but current_year is not described in the schema either. The description adds no parameter-level detail beyond what the schema provides, so for the covered url param it's baseline. The undocumented current_year param in the schema is not compensated by the description, which mentions 'older years' generically but not the current_year input.

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

  Purpose5/5

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

  The description states a specific action ('Flag older years, relative time claims, pricing or limits, and dated screenshots for human verification') against a specific resource (content freshness). It clearly distinguishes from siblings like aeo_ai_readability_audit and aeo_entity_coverage by scoping to freshness/dated-content concerns. The verb 'flag' plus target categories gives a precise purpose.

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

  Usage Guidelines3/5

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

  The description explains what gets flagged and explicitly notes 'It does not declare flagged content incorrect,' which is a useful boundary. However, it gives no guidance on when to choose this over alternative audits (e.g., aeo_audit_page, aeo_ai_readability_audit) or when freshness auditing is inappropriate. No exclusions or alternatives named.

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

• bing_get_fetched_url_detailsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds mild context by clarifying it does NOT return the full dashboard report, which helps calibrate expectations. It doesn't add details beyond what annotations provide, so 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.

  Conciseness5/5

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

  Two sentences with zero waste. The first sentence states the purpose; the second immediately clarifies the negative scope (not the full dashboard report), which is valuable differentiation. Every word earns its place.

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

  Completeness4/5

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

  For a simple 2-parameter read tool with strong annotations and 100% schema coverage, the description is adequate. It correctly warns the agent not to expect the full UI report. Without an output schema, some return-format guidance would help, but for the tool's complexity level this is reasonably complete.

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

  Parameters3/5

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

  Schema coverage is 100% for both parameters (url='Exact live page URL', site_url='Exact verified site URL returned by bing_list_sites'). The schema already documents both parameters thoroughly, including a cross-tool reference for site_url. The description adds no further embedded field semantics, so baseline 3 is correct.

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

  Purpose5/5

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

  The description states a specific verb+resource: 'Get Bing's stored fetch details for one URL.' It clearly distinguishes from the broader 'full URL Inspection SEO/GEO report shown in Bing's dashboard,' differentiating it from siblings like bing_get_url_info and bing_get_page_stats.

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

  Usage Guidelines3/5

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

  The description tells the agent what this tool returns (stored fetch details, not the full SEO/GEO report), implying usage for raw fetch diagnostics. However, it doesn't explicitly say when to prefer this over alternatives like bing_get_url_info or bing_get_url_traffic_info, nor state exclusions about when NOT to use it.

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

• bing_get_url_submission_quotaA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description aligns with these annotations and adds minimal context (that it returns quota/remaining count before submission). There are no rate limit or auth details disclosed, but for a read-only quota check, the annotations carry the safety burden adequately.

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

  Conciseness4/5

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

  The description is a single concise sentence with zero waste. It's front-loaded with the primary action ('Check how many URL submissions remain') and adds a usage qualifier. It's appropriately sized for a simple tool with one parameter.

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

  Completeness4/5

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

  For a single-parameter read-only quota check tool with full schema coverage and strong readOnly/idempotent annotations, the description and structured fields together provide sufficient completeness. It connects to related sibling tools (bing_list_sites for source, bing_submit_* for the follow-on action) implicitly through naming. An output schema would've added detail on what the quota response contains, but its absence isn't a major gap for this simple tool.

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

  Parameters4/5

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

  Schema coverage is 100%, and the single parameter (site_url) is well-documented in the schema as 'Exact verified site URL returned by bing_list_sites.' This cross-reference to bing_list_sites adds valuable semantics beyond the raw schema, telling the agent where to source the valid value. With one fully-documented parameter, the description doesn't need to add more, though it doesn't restate the parameter in prose.

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

  Purpose4/5

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

  The description states a clear purpose: 'Check how many URL submissions remain before submitting URLs.' This uses a specific verb+resource and the 'before submitting URLs' phrase provides usage context. It distinguishes itself from the sibling submission tools (bing_submit_url, bing_submit_url_batch) by focusing on quota checking rather than actual submission, though it doesn't explicitly name those siblings.

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

  Usage Guidelines4/5

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

  The description says to use this 'before submitting URLs,' which provides clear timing context for when to invoke it. While it doesn't explicitly exclude alternatives or name sibling alternatives, the relationship to the submission tools is clear from the description phrasing. The context is adequate for an agent to know this is a pre-flight check tool.

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

• aeo_autofix_pageA
  3.9/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description aligns with these: 'always requires approval; it never publishes' reinforces the read-only safety profile. The description adds clarity about the approval gate and non-publishing behavior that annotations don't fully convey.

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

  Conciseness5/5

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

  A single dense but complete sentence covers purpose, authorization gate, and constraints. It's front-loaded and every clause earns its place. Slightly dense but efficient.

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

  Completeness4/5

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

  With 8 parameters and only 25% schema description coverage, the description could be richer, but the tool is structurally simple (no nested objects, no output schema, and the schema's one required param 'url' is self-describing). The 'optional apply caller-supplied replacements' phrase covers the main customization path. Given the modest complexity and good annotations, the description is reasonably complete.

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

  Parameters2/5

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

  Schema coverage is only 25%, so the description must compensate. It explains that replacements correspond to caller-supplied 'exact' matches in the latest WordPress content, tying to content_html and proposed_changes semantics. However, it doesn't elaborate on current_year, primary_entity, or related_entities, leaving the other 75% undocumented.

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

  Purpose5/5

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

  The description gives a specific verb+resource ('audit a public page, then optionally apply replacements') and clearly states it returns a diff. It distinguishes from the many sibling scan/audit tools by emphasizing the apply-replacements and approval-gated behavior. Clear and distinct.

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

  Usage Guidelines3/5

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

  The description implies it's for when you need approval-gated fixes that go beyond scanning — it never publishes and always requires approval. However, it doesn't explicitly contrast with siblings like aeo_prepare_wordpress_fixes or aeo_audit_page, so an agent isn't clearly told when to prefer this over those.

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

• aeo_schema_recommendationsA
  3.9/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which already cover the safety profile. The description adds value by specifying the visible-page scope ('visible page'), implying it only analyzes rendered/visible content and not hidden or non-rendered pages. This is useful behavioral context that complements 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.

  Conciseness4/5

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

  A single, information-dense sentence that front-loads all three actions (validate, list, assess) and enumerates the target schema types. No filler or redundancy. Could arguably note output behavior, but for its length it's efficient.

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

  Completeness4/5

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

  For a read-only, single-parameter audit tool with strong annotations and full schema coverage, the description covers the three core capabilities and the specific schema types evaluated. The absence of an output schema means return-format details aren't required. It's complete for a validation/recommendation tool of this complexity.

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

  Parameters3/5

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

  Schema coverage is 100% with a single 'url' parameter, which the schema already documents as 'Public webpage URL'. The description adds the 'visible page' qualification implying the URL must render content, but doesn't add format or behavioral detail beyond what the schema provides. With full coverage, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Validate', 'list', 'assess') with a clear resource (JSON-LD syntax, existing schema types, markup fit). It explicitly enumerates the schema types evaluated (Article, BreadcrumbList, FAQPage, HowTo, Product, Review), distinguishing it from sibling aeo_* audit tools which focus on readability, entity coverage, or freshness rather than structured data.

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

  Usage Guidelines3/5

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

  The description implies this executes when checking schema/structured-data markup on a visible page, but it doesn't explicitly state when to choose this over siblings like aeo_audit_page or aeo_multilang_schema_parity. No explicit exclusions or alternatives are named, though the narrow scope (schema types) is inferable from context.

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

• aeo_ai_overview_previewA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is well-covered. The description adds behavioral value by clarifying the extractive-only nature (no inference beyond page content) and the confidence-reporting mechanism based on page structure. This adds genuine context beyond the annotations about what the tool does and doesn't do.

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

  Conciseness5/5

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

  Two sentences, zero waste. The first sentence covers function and behavior, the second clarifies a key limitation. Everything earns its place.

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

  Completeness4/5

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

  With strong annotations, a single fully-documented parameter, and no output schema, the description covers the essential scope well. The clarification about not simulating a proprietary AI platform is important for setting expectations. Missing minor details like what the output format looks like, but without an output schema this is acceptable for a preview/analysis tool.

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

  Parameters3/5

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

  Schema coverage is 100% with a single 'url' parameter fully documented as 'Public webpage URL'. The description adds no additional parameter detail beyond what the schema provides, but with full coverage and one simple param, the baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool builds an extractive answer using only on-page passages and reports confidence based on page structure. It distinguishes itself from proprietary AI platform simulation. However, while clear, it doesn't explicitly differentiate from sibling aeo_* tools like aeo_ai_readability_audit or aeo_entity_coverage, though the 'page-only' scope and 'not proprietary' distinction help.

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

  Usage Guidelines4/5

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

  The description implies this is used when you want a page-native, extractive AI answer preview rather than a simulated proprietary AI response. The explicit 'It does not simulate a proprietary AI platform' gives context about what NOT to expect. However, it doesn't name alternative tools to use for proprietary simulation, nor give explicit when-to-use vs when-not scenarios.

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

• aeo_compare_pagesA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile well. The description adds a useful behavioral note that it 'does not copy competitor content,' which clarifies the output is analytical rather than derivative. Given strong annotation coverage, a 3 is appropriate as the description supplements but doesn't need to be extensive.

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

  Conciseness5/5

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

  Two sentences, zero filler. The first sentence states purpose and scope precisely, the second sentence disambiguates the tool's behavioral boundary. Every word earns its place.

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

  Completeness4/5

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

  For a two-parameter tool with strong annotations (read-only, idempotent, open-world), the description effectively covers what an agent needs to know: what it does and what it won't do. Without an output schema, the description could ideally describe the return format, but the core purpose and constraints are clearly communicated.

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

  Parameters3/5

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

  Schema coverage is 50% — the two URI parameters have basic descriptions ('Your public webpage URL' and competitor URLs list). The description implies both parameters but doesn't add constraints beyond schema, such as URL format expectations or what makes a valid competitor URL. With 50% coverage, the description adds marginal value but doesn't fully compensate for the undocumented half.

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

  Purpose5/5

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

  The description states a specific verb ('Compare') with a clear resource ('one page vs up to five competitor pages') and a well-defined output ('find heading topics competitors cover that the page does not'). It clearly distinguishes from sibling tools like aeo_intent_coverage or aeo_entity_coverage, which address different aspects of content gaps.

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

  Usage Guidelines4/5

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

  The description clearly communicates when to use it: compare a page against competitor pages to find topical gaps. It also states an important exclusion ('It does not copy competitor content'), which helps agents understand it's for gap identification, not replication. However, it doesn't explicitly name alternatives or state when NOT to use it.

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

• aeo_internal_duplicate_checkA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the fetching behavior (reads pages) and the word-shingle similarity method. However, it doesn't disclose return format details, pagination, rate-limit behavior, or what happens when no duplicates are found. With solid annotations, 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.

  Conciseness5/5

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

  Two sentences total, front-loaded with action verb and scope, zero filler. The description efficiently conveys purpose, operational bounds, methodology, and interpretation of results in under 25 words.

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

  Completeness4/5

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

  For a read-only analysis tool with 100% schema coverage, complete annotations, and no output schema (so return values aren't separately documented), the description appropriately covers purpose, scope, method, and result interpretation. The only minor gap is not elaborating on the output format, but given the simplicity of the tool, this is largely complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters (urls with min/max count and format, similarity_threshold with range and default) are fully documented in the schema. The description adds the threshold concept ('flag a pair') which reinforces but doesn't extend the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the verb ('fetch... flag highly similar article bodies'), the specific resource (2-30 public pages), the method (word-shingle similarity), and the scope (internal near-duplicate content). It also explicitly distinguishes its output nature (review signals, not canonicalization decisions), which differentiates it from sibling tools like aeo_compare_pages.

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

  Usage Guidelines4/5

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

  The description gives clear operational parameters (fetch 2 to 30 public pages) and clarifies what the results should be used for (review signals, not decisions). While it implies the tool is for internal duplicate detection, it doesn't explicitly state when NOT to use it or name alternative tools, but the context of internal duplicate checking is clear enough.

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

• bing_submit_urlA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation nature is conveyed by structured data. The description adds the quota-consumption behavior, which is useful. However, it doesn't disclose auth requirements, whether submissions are reversible, or what the response contains. With annotations covering the safety profile, this is adequate but not rich.

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

  Conciseness5/5

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

  Two sentences convey the purpose, scope, and a key constraint (quota usage). Zero wasted words, fully front-loaded with the action verb.

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

  Completeness4/5

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

  For a write/submission tool with 100% schema coverage, full annotations, and no output schema, the description covers the essential semantics. The quota reference provides practical context. Could mention the distinction from the batch variant, but the combination of schema, annotations, and description is otherwise sufficient.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both url and site_url having inline descriptions. The description adds the quota dimension but doesn't elaborate on parameter relationships (e.g., that site_url must be the exact verified result from bing_list_sites, which the schema already states). Since coverage is full, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb+resource ('Submit one page URL to Bing for crawling') that clearly distinguishes it from siblings. It also mentions the submission quota, which contextually differentiates it from the batch variant (bing_submit_url_batch) and indexnow submission tools.

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

  Usage Guidelines4/5

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

  The description states it submits a single URL and references the account quota, suggesting quota-conscious usage. However, it doesn't explicitly contrast with bing_submit_url_batch, bing_submit_sitemap, or indexnow_submit_url, which are the obvious alternatives. The single-vs-batch distinction is implied via 'one page URL' but not made explicit.

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

• bing_submit_url_batchA
  4/5.0
  Behavior3/5

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

  The description adds context that the daily and monthly quota is checked first, and that URLs must be same-site and public. Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds a validation step and quota behavior beyond these. It doesn't describe response/return format or error behavior on failure.

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

  Conciseness5/5

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

  Two sentences, zero filler. Each sentence earns its place: the first states what/how it submits, the second states a behavioral constraint (quota check ordering). Highly front-loaded and efficient.

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

  Completeness4/5

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

  For a two-param, no-nested-object tool with 100% schema coverage, the description covers purpose, constraints, and quota behavior. It could mention failure handling or the response structure, but with full schema coverage and a simple mutation tool, it's reasonably complete.

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

  Parameters3/5

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

  Schema coverage is 100%, so both parameters (site_url, urls) are documented in the schema. The description adds the 'same-site', 'public', and '500' constraints that reinforce but don't deeply extend the schema. It references bing_list_sites for the exact site_url value, which is a useful cross-tool pointer, keeping this at baseline 3.

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

  Purpose5/5

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

  Description states a specific action (validate and submit up to 500 same-site public URLs) via a named route ('SubmitUrlbatch'). It clearly distinguishes from siblings like bing_submit_url (single URL) and bing_submit_sitemap by specifying batch submission with a count limit.

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

  Usage Guidelines4/5

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

  Description states parameters (same-site public URLs) and the limit (500) plus quota checking. It doesn't explicitly name alternatives or state when not to use it, but the sibling set makes the batch-vs-single distinction clear from the title alone.

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

• indexnow_submit_urlsA
  4/5.0
  Behavior3/5

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

  The description adds useful behavioral context: it validates the key file, accepts up to 10,000 URLs, and explicitly states 'This does not guarantee crawling or indexing.' However, it does not discuss auth requirements, quota/rate limits, or what happens on partial failure. The destructiveHint=false and openWorldHint=true annotations are consistent and not contradicted.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the primary action, and zero wasted words. The second sentence adds an important expectation-setting caveat about crawling guarantee. Very efficient.

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

  Completeness4/5

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

  For a batch submission tool, the description covers the key context: key validation, host scoping, URL types, size limit, and the non-guarantee caveat. No output schema exists, so the description doesn't need to explain return format. Slight gap on failure/partial-submission behavior, but this is reasonably complete for the tool's complexity.

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

  Parameters3/5

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

  Schema description coverage is 50%. The description references the site_url concept ('configured host') which aligns with the schema's 'Exact verified site URL returned by bing_list_sites'. The 'urls' parameter is described as 'added, updated, or deleted public URLs' in the description, adding change_type semantics. However, it doesn't detail the url maxLength (4096) or the 10,000 max that the schema already constraints. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb+resource: 'Validate the same-host key file and notify IndexNow about up to 10,000 added, updated, or deleted public URLs on the configured host.' It clearly distinguishes from siblings like indexnow_submit_url (single URL) and indexnow_validate_key (key validation only) by specifying the batch nature and URL-type scope.

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

  Usage Guidelines4/5

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

  The description clearly states when this tool is appropriate (notifying IndexNow about added/updated/deleted URLs on the configured host). It references bing_list_sites as source for site_url. It lacks an explicit 'when not to use' or alternative recommendation (e.g., indexnow_submit_url for single URL), but the sibling distinction is reasonably inferable.

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

• seo_scan_pageA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context about independent fetching ('does not use Bing's API') and lists what's checked. However, it doesn't disclose potential limitations like rate limits, timeouts for large pages, JS-rendered content handling, or what happens on fetch failure.

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

  Conciseness5/5

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

  Two tight sentences, zero waste. The first sentence packs the action, scope, and enumerated checks efficiently. The second sentence provides critical differentiation in four words. Every word earns its place.

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

  Completeness4/5

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

  For a read-only scanning tool with full annotation coverage and a single fully-documented parameter, the description is largely complete. The list of scanned dimensions (nine items) gives the agent a concrete sense of what the tool returns. Slight deduction for not covering edge-case behavior (e.g., non-200 status handling, authentication-required pages), but these are minor gaps for this tool type.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the url parameter is fully documented in the schema. The description adds minor context by specifying the URL must be 'public' and a 'webpage', slightly refining what kind of URL is acceptable. This aligns with the baseline 3 for full schema coverage; the description adds marginal value.

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

  Purpose5/5

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

  The description clearly states the verb (fetch and scan), the resource (one public webpage), and enumerates the specific SEO dimensions checked (HTTP, title, meta description, H1, image alt, canonical, robots, language, JSON-LD). It also differentiates from siblings by explicitly noting it does not use Bing's API, and the singular 'page' distinguishes from seo_scan_pages.

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

  Usage Guidelines4/5

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

  The description states it scans 'one public webpage' (limiting scope) and explicitly notes it does not use Bing's API, which helps distinguish from Bing siblings. However, it doesn't explicitly name alternative tools for when this tool should NOT be used, such as seo_scan_pages for multiple pages or bing_get_crawl_issues for API-based data. The 'Independently fetch' phrasing implies it bypasses indexing APIs but doesn't fully draw the boundary.

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

• aeo_audit_pageA
  4.1/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true, covering the safety profile (non-destructive, idempotent). The description adds the scope of checks run and the 'one public page' constraint and that it produces 'an extractive answer preview' with 'citable chunks,' giving the agent context on what the run examines without contradicting annotations.

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

  Conciseness5/5

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

  One dense sentence, front-loaded with the strongest signal ('Complete AI-search page audit'), then a compact enumeration of all checks. Zero filler, every clause earns its place.

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

  Completeness3/5

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

  For a complex 6-parameter tool with no output schema, the description enumerates the checks but leaves the parameters' roles ambiguous. The agent can infer primary_entity/related_entities/expected_intents/candidate_links/candidate inputs from the enumerated checks, but the schema provides little documentation and the description doesn't clarify parameter interplay or required inputs beyond url. Given optional parameters with defaults, the description is adequate but not complete.

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

  Parameters3/5

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

  Schema description coverage is only 17%, and the schema itself documents almost none of the parameters well (url has 'Public webpage URL', others rely on type/enum/defaults only). The description adds no parameter-level detail beyond vague category names like 'entity coverage' and 'intent coverage' that map loosely to primary_entity/related_entities and expected_intents. This is a real gap for 6 parameters, so a baseline 3 with description partly compensating but not fully is appropriate.

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

  Purpose5/5

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

  The description has a specific verb ('Run') and names 9 distinct check categories (readability, entity coverage, citation readiness, intent coverage, extractive answer preview, citable chunks, internal linking, schema, freshness) on 'one public page.' This clearly distinguishes it from the many sibling aeo_* single-purpose audit tools (e.g., aeo_ai_readability_audit, aeo_entity_coverage) which each do only one of these checks, making this the comprehensive/combined audit.

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

  Usage Guidelines4/5

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

  The description implicitly signals this is the 'complete' or bundled audit versus the granular sibling aeo_* tools, recommending it when a full comprehensive audit is desired. It doesn't explicitly state when NOT to use it or name alternative granular tools, but 'Complete AI-search page audit' and the enumerated checks make the use case clear for a page-level assessment.

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

• aeo_llms_txt_auditA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile well. The description adds meaningful context beyond annotations by noting llms.txt is 'a community proposal, not a ranking guarantee', which sets expectations about the output's significance. This is valuable framing an agent would otherwise not know.

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

  Conciseness4/5

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

  Two sentences, front-loaded with the core purpose. The first sentence captures the entire audit flow; the second adds a single relevant caveat about llms.txt being a community proposal. No wasted words, though it could arguably be trimmed further.

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

  Completeness4/5

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

  For a read-only audit tool with full schema coverage and strong annotations, the description is adequately complete. It covers what is checked (file existence, links, heading, canonical comparison) and sets proper expectations. No output schema exists, so the description could note what the result looks like, but the stated scope is sufficient for the tool's simplicity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters (site_url and canonical_urls) are already documented in the schema. The description adds purpose-level meaning for canonical_urls (comparing against it) but doesn't add format or behavioral details beyond the schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb (check/inspect/compare), the resource (root-level llms.txt Markdown file), and the specific scope (links, heading, and comparison with canonical/hub URLs). It is distinct from sibling tools which cover Bing rank/traffic stats, SEO scans, and AEO content audits — this one uniquely targets the llms.txt file.

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

  Usage Guidelines4/5

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

  The description implies usage for auditing an llms.txt file against canonical URLs, which gives clear context. However, it doesn't explicitly state when NOT to use it or name an alternative tool, though the distinct domain (llms.txt vs Bing/SEO metrics) makes the context reasonably clear.

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

• aeo_find_ai_traffic_opportunitiesA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds a useful privacy guarantee ('GA4 data stays in this local MCP process') which is the primary behavioral addition. It doesn't describe return format, thresholds logic, or error handling, but the annotations carry the main burden and the description adds the meaningful local-processing note.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the core purpose, minimal waste. Every clause contributes: what it pulls, what it returns, and the privacy note. No redundant framing or repetition of schema details.

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

  Completeness4/5

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

  With 9 parameters and 100% schema coverage, the description explains the core workflow without needing to list every param. It lacks an output schema so it doesn't detail the return structure, but for a complex multi-input matching tool the description is complete enough to select and invoke. The distinction between CSV and rows inputs plus the privacy guarantee covers the non-obvious aspects.

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

  Parameters4/5

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

  Schema coverage is 100%, so the schema documents all 9 parameters. The description adds value by explaining the matching logic ('match them with an aggregated GA4 CSV or GA4 rows'), which clarifies how ga4_csv, ga4_rows, and source interrelate. It also conveys the filtering intent behind maximum_ai_traffic and minimum_bing_impressions beyond their raw schema descriptions. Marginally above baseline 3 due to the workflow framing.

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

  Purpose5/5

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

  The title and description clearly state the purpose: find pages with high Bing impressions but low AI-referral traffic. The verb 'find' plus the specific resource ('high-impression, low-AI-traffic pages') and the mechanism ('Bing top-page statistics matched with GA4 data') make it specific and it clearly distinguishes from sibling bing_* tools by combining Bing stats with GA4 data.

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

  Usage Guidelines4/5

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

  The description explains the tool pulls Bing's top-page statistics and matches with GA4 CSV or GA4 rows, giving clear context on data inputs. It doesn't explicitly state when-not-to-use or name alternatives, but the 'GA4 data stays in this local MCP process' adds a privacy-relevant usage note. Lacks explicit exclusions versus sibling AEO tools but the workflow is clear enough.

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

• aeo_internal_link_opportunitiesA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value beyond annotations with 'It never invents destination URLs' — a meaningful behavioral constraint about output trustworthiness. However, it doesn't disclose output format or what happens when the inventory is empty, though with rich annotations this is acceptable.

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

  Conciseness5/5

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

  Two sentences, zero waste. Each sentence earns its place: the first states the action and mechanism, the second adds a trustworthiness guarantee about behavior. Front-loaded and extremely efficient.

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

  Completeness4/5

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

  The tool has 2 params (1 required), candidate_links contains nested objects with keywords, and there's no output schema. The description covers the core contract well: audit existing links, match to supplied inventory, never invent URLs. It could mention what the output looks like (since there's no output schema), but given the read-only, idempotent annotations and the relative simplicity of the tool, it's largely complete for the agent to select and approximate usage correctly.

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

  Parameters4/5

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

  Schema coverage is only 50%, so the description must compensate partially. The description explains the core mechanism — matching page topics to the supplied inventory — which directly clarifies the purpose of candidate_links. The 'never invents destination URLs' clause reinforces that url and candidate_links work together. The 'Audit existing internal links' phrase adds context for the url parameter that the schema's minimal 'Public webpage URL' doesn't provide.

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

  Purpose5/5

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

  The description clearly states the verb ('Audit') and the resource ('existing internal links'), and explains the specific method: matching page topics to a supplied inventory of real internal URLs. The statement 'It never invents destination URLs' is a powerful clarification given the sibling tools (many bing_* tools retrieve data, while aeo tools audit aspects). This distinguishes it well from aeo_internal_duplicate_check and other aeo audit tools.

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

  Usage Guidelines4/5

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

  The description implies that this tool works on a supplied inventory of URLs, and the 'never invents destination URLs' phrase signals that users must provide the candidate URL inventory (the candidate_links parameter). It's clear this is a read-only audit. However, it doesn't explicitly state when to use it vs alternatives like aeo_internal_duplicate_check or list cases where it should not be used, though the sibling distinctions are reasonably inferable.

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

• aeo_plan_page_fixesA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile well. The description adds the key behavioral trait that this is a planning-only tool (no fixes applied), which is a meaningful complement to the annotations. The phrase 'turn every detected issue into an exact fix plan' clarifies the tool produces a plan rather than executing changes.

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

  Conciseness5/5

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

  One concise, information-dense sentence that front-loads the core purpose ('Scan one live page and turn every detected issue into an exact fix plan') and adds valuable detail about fix categories. Zero filler words, no redundancy with schema or annotations.

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

  Completeness4/5

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

  For a tool with one well-documented parameter, comprehensive safety annotations, and no output schema, the description covers the essential behavior. It omits edge details like how many issues will be examined, timeout limits for large pages, or whether the plan output format is standardized - but given the tool's simplicity and annotation coverage, the description is largely complete. The scoping qualifier 'one live page' appropriately sets expectations.

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

  Parameters3/5

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

  Schema description coverage is 100% and there is only one parameter (url) with format 'uri' and a clear description already in the schema. The tool description references scanning 'one live page' which maps to the url parameter but adds no format validation details, protocol expectations, or URL constraints beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.

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

  Purpose5/5

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

  The description uses a specific verb 'Scan' with a clear resource ('one live page') and states the deliverable: 'turn every detected issue into an exact fix plan'. It enumerates the fix categories (WordPress content, SEO metadata, schema, theme, manual review), which distinguishes it clearly from sibling tools like aeo_audit_page (which audits but doesn't plan fixes), aeo_prepare_wordpress_fixes (narrower scope), and aeo_autofix_page (applies fixes rather than planning them).

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

  Usage Guidelines4/5

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

  The description communicates a clear input context ('live page', 'scan') and a distinct output ('fix plan') that differentiates it from auditing-only siblings. However, it doesn't explicitly state when NOT to use it or name alternative tools for edge cases (e.g., using aeo_autofix_page if the user wants fixes applied directly, or aeo_audit_page if only analysis is needed).

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

• aeo_prepare_wordpress_fixesA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, setting a strong safety baseline. The description adds value by clarifying the tool returns 'exact changes and unresolved items for review' (a non-destructive, review-oriented workflow) and explicitly frames it as a prerequisite step before a separate publishing action. This complements rather than repeats 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.

  Conciseness5/5

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

  Two sentences, zero filler. Each clause earns its place: the action ('prepare'), the scope ('duplicate H1s and alt text'), the non-publishing constraint, the output ('exact changes and unresolved items'), and the integration point ('before the WordPress MCP updates'). Front-loaded with the most critical information first.

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

  Completeness4/5

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

  For a review-oriented preparation tool with strong annotations (read-only, non-destructive, idempotent) and high schema coverage, the description covers the essential workflow: what it fixes, that it doesn't publish, and that it returns reviewable output. Since there is no output schema, the description's note about returning 'exact changes and unresolved items for review' partially compensates. A slight gap: it doesn't clarify what happens with unrecognized issue_codes or how the theme_renders_title_h1 flag interacts with the H1 fix, but given the tool's preparation-only nature, this is acceptable.

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

  Parameters3/5

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

  Schema description coverage is 80% (4 of 5 parameters have descriptions in the schema). The description adds the key context that content_html should be the 'Latest WordPress post body HTML' and that issue_codes like 'multiple_h1' or 'image_missing_alt' are expected values, plus clarifies image_alt_texts maps alt text to specific image URLs. However, the description doesn't explain the relationship between issue_codes and the specific fix behavior, leaving some added value unrealized. Baseline 3 is appropriate given high schema coverage and modest description add-ons.

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

  Purpose5/5

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

  The description uses a specific verb+resource combination ('prepare corrected WordPress post HTML') with clear scope ('duplicate content H1s and missing or empty image alt text'). It clearly distinguishes itself from publishing tools by stating 'do not publish' and 'before the connected WordPress MCP updates the post', and contrasts with the sibling tool aeo_autofix_page which implies direct application.

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

  Usage Guidelines4/5

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

  The description explicitly states this is a preparation step ('Prepare, but do not publish') and indicates it should be used before the WordPress MCP update, establishing clear context. However, it doesn't explicitly name alternative tools or describe when NOT to use it versus aeo_autofix_page, which appears to be the closest sibling that actually applies changes.

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

• indexnow_validate_keyA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by stating 'The key is never returned' — a meaningful behavioral disclosure about output confidentiality. It also reveals it performs a remote check (public accessibility, host location), which is useful operational context beyond 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.

  Conciseness5/5

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

  One sentence, zero waste. Front-loads the verb and subject, lists the three check criteria compactly, and adds the key confidentiality note as a meaningful final clause. Every element earns its place.

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

  Completeness4/5

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

  For a single-parameter read-only validation tool with complete schema coverage and good annotations, the description covers the essential behavioral points: what is checked, the fact that the key is never returned, and the tie to a verified site URL. It doesn't describe failure modes or return values, but given no output schema exists and this is a straightforward validation check, the coverage is reasonably complete.

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

  Parameters4/5

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

  Schema coverage is 100% for the single parameter, documenting it as an 'Exact verified site URL returned by bing_list_sites'. The description adds context by implying the site_url determines which site/domain's key file to validate against, and that the verified URL's host matters for the host-location check. With one well-documented parameter, the description's contribution is modest but adequate.

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

  Purpose5/5

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

  The description uses a specific verb ('Check') with a clear resource ('IndexNow key file') and enumerates three concrete criteria: publicly accessible, contains the configured key, and on the configured site's host. It clearly distinguishes itself from sibling tools like indexnow_submit_url/indexnow_submit_urls, which submit URLs rather than validate key setup.

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

  Usage Guidelines3/5

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

  The description states the tool checks local key configuration but doesn't explicitly state when to use it vs alternatives (e.g., before submitting URLs). It implies it's a prerequisite verification for IndexNow submission workflows but doesn't name any alternative or exclusion conditions. The sibling names suggest it pairs with indexnow_submit_* tools, but this isn't stated.

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