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

With no annotations, the description must carry the burden of behavioral disclosure. It states the data source ('Bing knows') and pagination, which implies a read-only operation. However, it does not mention authentication needs, rate limits, or how incomplete/incorrect siteUrl values are handled. Some relevant behavioral context is missing.

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

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

Two sentences deliver the essential behavior, both modes, and pagination without wasted words. The most important distinction (with/without `url`) is front-loaded, and every clause earns its place.

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

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

The description covers the two output forms and pagination, which is the core information an agent needs. It does not specify page size or error behavior, but given the simple parameter set and no output schema, the key context is present. Minor gaps exist around siteUrl behavior, though the schema covers the default.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema by explaining that `url` changes the shape of the output (counts vs. linking pages/anchors) and that `page` controls pagination. This goes beyond the schema's basic field definitions.

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

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

The description clearly states the tool returns inbound links known to Bing and distinguishes two modes: per-page counts without `url`, and linking pages/anchor texts with `url`. This specific behavior differentiates it from sibling tools like `url_info` or `query_stats` without needing to inspect schemas.

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

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

The description gives clear internally structured usage context by explaining when to pass `url` versus omit it, and mentions pagination via `page`. It does not explicitly name alternative tools or exclusion conditions, but the mode-based guidance is enough for correct invocation in most cases.

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

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

With no annotations, the description carries the full burden. It does disclose what kind of data is returned (URLs with issue types and HTTP codes) and implies a read-only listing, but it does not mention potential limitations, result format, pagination, data freshness, or any required permissions.

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

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

The description is compact and free of filler. It front-loads the key concept (concrete URLs with crawl issues) and adds useful qualifiers in a single sentence, though it is a fragment rather than a complete sentence.

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

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

For a tool with one optional parameter and no output schema, the description adequately states the core purpose and return content. However, it does not clarify response structure, ordering, limits, or whether the returned list is exhaustive, which an agent might need for correct invocation.

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

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

The single parameter siteUrl is fully documented in the schema, including its role and default environment variable. With 100% schema description coverage, the baseline is 3 even though the description itself adds no parameter-level detail.

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

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

The description identifies the resource (URLs with crawl issues found by Bing) and specifies the types of issues (HTTP errors, robots blocks, malware flags) and includes the HTTP code. It is clear enough to distinguish this from siblings like crawl_stats (aggregate statistics vs. specific URLs), though it lacks an explicit verb such as 'list' or 'get'.

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

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

There is no guidance on when to use this tool versus alternatives such as crawl_stats, url_info, or submit_urls. No exclusions or preconditions are mentioned, and the description does not reference any sibling tool or differentiator.

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

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

With no annotations, the description carries the burden of explaining behavior. It does disclose what the tool returns—specific crawl counts, HTTP status buckets, robots.txt blocks, and errors—so an agent understands the general read-only nature. However, it omits behavioral details like the time range covered, aggregation/granularity, or how 'over time' is represented in the response.

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

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

The description is a single dense sentence that front-loads the core purpose and then lists specific metric categories without filler or redundant wording. Every listed item adds useful information about the tool's scope.

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

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

The metric list provides a reasonable overview and the schema is simple with one optional parameter, so basic invocation is possible. Yet the absence of an output schema and any mention of default time period, date-range handling, or response shape leaves an agent uncertain about how to interpret 'over time'.

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

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

The only parameter, siteUrl, is already fully described in the schema with a clear default and example, giving 100% schema description coverage. The tool description adds no additional meaning for this parameter, 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.

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

The description clearly identifies the resource as 'Bingbot crawl activity over time' and enumerates the major metric categories (pages crawled, in-index counts, HTTP buckets, robots.txt blocks, crawl errors). It is specific enough to distinguish this from generic stats tools, though it does not explicitly name or contrast sibling tools such as crawl_issues.

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

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

Usage is implied by the content: an agent can infer to use this when it needs Bingbot crawl activity metrics. However, there is no explicit when-to-use or when-not-to-use guidance, and the inclusion of 'crawl errors' creates potential overlap with the sibling tool crawl_issues without any differentiation.

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

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

With no annotations, the description must carry the behavioral burden. It discloses a key prerequisite, the external pinging behavior, and the 'instant and quota-free' nature. It does not disclose failure modes, network response behavior, or consequences of an invalid/missing key.

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

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

Two tight sentences with no filler. The key requirement (<key>.txt at site root) is surfaced alongside the primary purpose, making it easy for an agent to parse and act on.

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

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

For a simple single-parameter tool with no output schema, the description covers the essential action and prerequisite. Minor gaps remain around URL limits, error handling, and how the key file requirement is validated, but nothing critical is missing for basic invocation.

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

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

Schema description coverage is 100%, and the sole parameter is already well described as fully-qualified URLs. The tool description adds little beyond restating that URLs are for added/updated content, which is adequate but not additive.

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

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

The description identifies a specific verb ('Ping'), a specific resource ('IndexNow network'), and the intent ('URLs added or updated'). It clearly differentiates itself by naming unique networks, though it does not explicitly contrast with sibling tools like submit_urls.

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

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

The description implies when to use it: when URLs have been added/updated and instant, quota-free notification to IndexNow is desired. However, it does not provide explicit guidance on when not to use it or what alternatives like submit_urls are better for.

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

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

With no annotations provided, the description carries the full burden. It discloses the data source, the nature of the result ('real numbers'), the simplicity of authentication, and the behavioral switch for related:true. It stops short of stating read-only status, pagination, or rate limits, but it is still substantially transparent.

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

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

Two sentences with no filler. The core result and data source lead, the related branch follows, and the default range is stated at the end. Every sentence earns its place.

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

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

For a lookup-style tool with no output schema and full schema documentation, the description covers purpose, authentication, related mode, and date defaults. The main gap is the exact response shape or field names for returned volumes, but this is a minor omission for this tool's simplicity.

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

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

Schema coverage is 100%, so the baseline is 3 even without additional parameter detail. The description adds little beyond restating the related-mode behavior and the trailing-3-months default, both of which the schema already documents.

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

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

States exactly what the tool computes: Bing search-impression volume for a keyword over a date range. It also names the related-keywords mode, and its scope is distinct enough from sibling stats tools that an agent can infer what it is for.

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

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

Provides useful context such as the default trailing 3-month range, the credential requirement, and the related:true behavior. However, it never explicitly says when to choose this tool over sibling tools like query_stats or page_stats, so usage guidance is implied rather than stated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the output contents (status, URL counts, crawl time), which is useful, but it does not explicitly state side effects or confirm read-only behavior. For a simple list operation this is acceptable, but more context (e.g., no mutation, pagination behavior) would improve transparency.

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

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

The description is a single, information-dense sentence with no wasted words. It front-loads the resource ('Sitemaps Bing knows') before the supporting details, making it quick to parse.

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

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

For a one-parameter list tool with no output schema, the description covers the resource scope and the returned data fields effectively. The optional siteUrl is left to the schema, which is appropriate. A minor gap is the lack of mention of pagination or the possibility of an empty list, but this is not critical.

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

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

The schema provides 100% coverage for the only parameter, siteUrl, including its default behavior. The description adds no parameter-specific information, which is fine because the schema already documents it fully.

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

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

The description clearly identifies the resource ('Sitemaps Bing knows for the site') and the data returned (processing status, URL counts, last-crawl time). It differentiates from sibling tools like submit_sitemap and remove_sitemap by focusing on the current known state, though it lacks an explicit verb like 'Lists'.

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

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

No guidance is given on when to use this tool vs alternatives. Sibling tools like submit_sitemap and remove_sitemap are present, but the description provides no contrasts or conditions for selecting this one.

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

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

No annotations are present, so the description carries the behavioral burden. It discloses the operation is a list and that results include verification status, but it does not mention pagination, output format, or whether unverified sites are included. This is adequate for a simple read-only list 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.

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

A single sentence that is front-loaded and contains no filler. It states the action, the resource, and the key output attribute efficiently.

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

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

For a zero-parameter list operation with no output schema, the description is reasonably complete: it names the scope and what is returned. It could mention pagination or result fields, but given the simplicity, the gap is minor.

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

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

The input schema has zero parameters and the schema description coverage is 100%, so there is nothing for the description to compensate for. The description correctly adds no parameter details because none exist.

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

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

The description clearly states the verb (list), the resource (sites accessible to the Bing Webmaster Tools API key), and adds a meaningful qualifier (with verification status). It is immediately distinguishable from sibling tools like list_sitemaps or query_stats.

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

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

The description explains what the tool does but gives no guidance about when to choose it over alternatives or when not to use it. While the scope 'this API key can access' provides some context, there is no explicit routing or exclusions.

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

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

With no annotations, the description carries the disclosure burden. It does reveal the core output shape (top pages with impressions and clicks), but it does not mention ranking criteria, time range, result limits, or whether the data is aggregate or dated. This is minimally adequate for a simple read-only stats tool.

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

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

The description is a single, efficient sentence that front-loads the key purpose and includes the most important output detail. There is no redundant wording or filler.

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

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

For a one-parameter tool with no output schema, the description states the essential result: page-level impressions and clicks from Bing search traffic. It is slightly incomplete regarding time range and ranking definition, but enough for an agent to select and invoke the tool confidently.

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

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

The only parameter, siteUrl, has full schema description coverage, so the schema already explains it. The tool description adds no additional parameter context, but none is needed given complete schema coverage.

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

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

The description clearly states the resource ('top pages') and the metric ('Bing search traffic', 'impressions and clicks per page'), so an agent can understand what the tool returns. It does not explicitly compare against sibling tools like query_stats or rank_traffic_stats, so it falls just short of full differentiation.

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

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

The description implies this is for page-level traffic stats, but it provides no explicit guidance on when to choose this tool over sibling tools such as query_stats or rank_traffic_stats. There are no stated exclusions, prerequisites, or alternative conditions.

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

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

With no annotations, the description carries the disclosure burden. It does disclose the data scope and the ~6-month trailing period, which is useful, but it omits output format, pagination, limits, and any caveats about siteUrl resolution, leaving partial transparency.

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

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

The description is a single efficient sentence with no filler. It front-loads the main subject, then lists the relevant metrics and the time period, making it well structured and appropriately sized.

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

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

For a simple read-only stats tool with one optional parameter, the description conveys the returned metrics and the time window. Without an output schema, it explains return content at a high level, but leaves details like ordering and row count unspecified, so it is not fully complete.

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

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

The schema already describes siteUrl, including its default to the BING_SITE_URL environment variable, at 100% coverage. The description adds no extra parameter meaning, 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.

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

The description identifies the resource ('Top search queries on Bing for the site') and the metrics (impressions, clicks, average position), making the tool's function clear. It does not explicitly contrast with siblings like page_stats or keyword_research, so it falls short of full differentiation.

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

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

The description implies usage when site-level search query stats are needed, and the trailing-period qualifier adds context. However, it provides no explicit guidance on when to prefer this tool over siblings or 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.

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

With no annotations, the description carries the full burden of disclosing behavior. It states what data is returned (daily impressions/clicks for the whole site), but it does not mention read-only status, output format, time range, aggregation behavior, or any operational constraints.

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

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

The description is a single, tightly worded sentence with no filler. It is front-loaded with the core data type, though it omits a verb, making it slightly less effective than a full imperative phrase.

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

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

The description is minimal for a tool with no output schema and no annotations. It does not explain the shape of the trend data, the date range covered, or how this tool should be selected over the many sibling stats tools. An agent would need additional inference or experimentation.

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

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

Schema coverage is 100%, and the single siteUrl parameter is already well documented with an example and default environment variable. The description adds no additional parameter semantics, but the schema sufficiently compensates.

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

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

The description clearly identifies the resource: a daily trend of Bing impressions and clicks for the whole site. It lacks an explicit verb like 'retrieve' or 'show', but the intent is unambiguous and the whole-site scope helps differentiate it from page-level or query-level stats.

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

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

There is no guidance about when to use this tool versus siblings like query_stats, page_stats, or crawl_stats. No alternatives, exclusions, or selection criteria are mentioned, leaving the agent to infer the tool's role from its name and minimal description.

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

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

There are no annotations, so the description carries the behavioral disclosure burden. It does disclose one important behavioral trait: removing the sitemap submission does not delete the actual file. However, it does not mention authorization requirements, irreversibility, or what happens if the sitemap was not previously submitted, leaving some behavioral ambiguity.

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

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

The description is a single sentence that states the action, the scope, and an important caveat without any filler. Every part of the sentence adds value, and the caveat is placed at the end where it cleanly qualifies the operation.

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

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

For a tool with only two parameters, one required, and no output schema, the description is sufficiently complete for correct invocation. The schema documents the parameters, and the description conveys the operation's purpose and its key non-destructive caveat. It could be enriched by mentioning response behavior or prerequisites, but the current combination of schema and description is adequate.

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

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

The input schema provides full descriptions for both parameters (feedUrl and siteUrl), including the default for siteUrl, so schema coverage is 100%. The description adds no additional parameter-level meaning, but none is needed because the schema already documents both parameters adequately.

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

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

The description uses a specific verb ('Remove') with a specific resource ('a submitted sitemap') and scopes it to Bing Webmaster Tools. The parenthetical 'does not delete the file' further clarifies the boundary of the operation, making the purpose unambiguous and distinct from a destructive file deletion.

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

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

The description clearly indicates when to use the tool: when a previously submitted sitemap needs to be removed from Bing Webmaster Tools. It also gives an explicit non-effect ('does not delete the file'), which helps prevent misuse. It does not name sibling tools or describe when to prefer list_sitemaps or submit_sitemap, but the usage context is clear.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It communicates that the action is a submission and that resubmission is allowed, but it does not disclose side effects, permissions, validation behavior, or what response the caller should expect. For a mutation-like operation, this is a meaningful gap.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the core action, and the parenthetical 'or resubmit' efficiently captures an important nuance without bloating the text.

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

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

The tool is simple, has only two parameters, and the schema covers both fully, so the description does not need to explain parameter details. However, with no annotations or output schema, the description could still be more complete by noting prerequisites, expected response behavior, or when to prefer a sibling tool like submit_urls.

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

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

The input schema already documents both parameters with 100% description coverage, including the feedUrl example and the siteUrl default behavior. The description adds no parameter-specific meaning beyond 'submit a sitemap URL', 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.

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

The description states a specific action, 'Submit (or resubmit)', and a clear resource, 'a sitemap URL for the site.' It conveys the core behavior and distinguishes it from sibling tools like list_sitemaps and remove_sitemap by the submit/resubmit verb, though it does not 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.

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

The phrase 'Submit (or resubmit)' implies the tool should be used when adding a new sitemap or refreshing an existing one, but it provides no explicit when-to-use guidance or exclusions relative to sibling tools such as submit_urls, indexnow, or remove_sitemap. The usage context is implied rather than stated.

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

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

With no annotations, the description carries the burden, and it does add useful behavior: the submission limit, the response includes remaining daily/monthly quota, and the ownership constraint. It doesn't cover errors, idempotency, or authentication, so it's 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.

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

Two tight sentences: the first states the action and limit, the second adds the quota response and the ownership constraint. No filler or redundancy.

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

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

For a two-parameter tool with full schema coverage, the main caller-facing facts are present: what it submits, the 1-500 limit, the site requirement, the optional siteUrl/default, and the quota in the response. It could add error behavior or explicit alternative routing, but it is largely complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the 500-URL ceiling and domain ownership, but it doesn't add meaningful semantic detail beyond what the parameter descriptions already provide.

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

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

Description names a specific action ('Push up to 500 URLs of the site into Bing's crawl queue') and identifies the underlying operation as SubmitUrlBatch, which clearly distinguishes it from related siblings like submit_sitemap and indexnow.

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

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

The context is clear: use this tool to submit a batch of up to 500 site URLs for crawling. However, it doesn't provide explicit guidance on when to choose this over the closely related sibling tools (submit_sitemap, indexnow) or state exclusions.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does convey a read-only informational lookup by saying 'What Bing knows about one URL' and lists the returned data categories. However, it does not mention caveats such as the data being last-known rather than live, authentication requirements, or behavior for URLs outside the registered site.

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

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

The description is a single, compact sentence that front-loads the tool's purpose and immediately lists the key output categories. Every part of the sentence contributes useful information with no wasted words.

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

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

For a simple lookup tool with two parameters and no output schema, the description adequately covers what the agent can expect in the result: discovery date, last crawl date, HTTP status, and document details. It does not cover error scenarios, but the schema handles the required and optional parameters sufficiently.

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

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

Schema description coverage is 100%, so the schema already documents both parameters well. The description adds little beyond reinforcing that the URL belongs to the site, which is already stated in the schema. This meets the baseline for schema-heavy parameter documentation.

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

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

The description clearly states the tool's function: retrieving Bing's stored information about a single URL, including discovery date, last crawl date, HTTP status, and document details. It identifies a specific resource and scope, though it uses a noun phrase rather than a strong imperative verb like 'Get' or 'Retrieve'.

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

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

The description gives no explicit guidance about when to use this tool versus siblings such as query_stats, page_stats, or crawl_stats. It merely implies per-URL scope through the phrase 'one URL of the site,' but does not state when alternatives are more appropriate.

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