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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the 'owned campaign' scoping nuance; it says nothing about pagination, result caps, or what happens when campaignType does not match the campaign.

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 front-loaded sentence with the resource and scope stated up front and zero redundant or filler text. Nothing could be removed without losing information.

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

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

With an output schema present, a fully described 3-parameter schema, and annotations covering safety and idempotency, the description supplies enough to select and call the tool correctly. The only looseness is the undefined term 'native configuration', which the output schema presumably resolves.

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

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

Schema description coverage is 100%, so all three required parameters (accountId, campaignId, campaignType) are already documented in the schema, including the enum semantics. The description adds no parameter-level meaning beyond the schema, which is the baseline case of 3.

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

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

States a specific verb (Read) and resource (ad groups) scoped to an owned campaign, which separates it from siblings like bing_get_ads or bing_get_campaigns by resource type. It does not explicitly name or contrast an alternative sibling, so it falls short of a 5.

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 'in an owned campaign' implies the caller must already have a campaign in an owned account, but there is no explicit when-to-use, when-not-to-use, or alternate tool routing. An agent must infer from the sibling list which getter to pick.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that responses carry native creative assets and URLs and that Microsoft omits unlisted formats, but says nothing about result size, pagination, or auth/scope requirements for the account-campaign hierarchy.

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 short sentences, both front-loaded with the highest-value information and no filler. It is efficient, though so terse that it leaves obvious questions unaddressed rather than being genuinely complete.

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?

An output schema exists and the input schema is fully documented, so the minimum is met. However, for a tool requiring five mandatory identifiers across the account/campaign/adGroup chain, the description does not indicate that all five must be resolved first or how to obtain them, which the schema alone only partially conveys.

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%, including the adTypes enum and the note that unlisted formats are omitted, so the description's adTypes remark largely restates the schema. Baseline 3 is appropriate; no extra meaning is layered onto accountId, campaignId, campaignType or adGroupId.

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

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

States a specific verb and resource ('Read ads') and enumerates what comes back (native creative assets, URLs, status). It is clear what the tool does, but it never distinguishes itself from overlapping siblings such as bing_list_ad_creatives, leaving the agent to guess which one to call.

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 when-to-use guidance, no prerequisites, and no named alternative. The only usage-adjacent sentence ('adTypes controls which formats Microsoft returns') is a parameter behavior, not a routing rule, and with 20 sibling tools the lack of differentiation is a real gap.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds that the output includes native creative configuration and status, which is useful, but it does not add deeper behavioral context such as permissions, rate limits, or pagination.

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 with zero waste, front-loading the action and resource. It is appropriately sized for a simple read tool.

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

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

Given rich annotations, a complete input schema, and an output schema, the description provides enough context to call the tool correctly. The only minor gap is lack of explicit guidance on when to choose this tool over related campaign or creative retrieval tools.

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 both required parameters (accountId and campaignId) are well documented in the schema. The description adds no parameter-specific meaning beyond the schema, 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.

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

The description states a specific verb (Read) and resource (Performance Max asset groups) and mentions the returned content (native creative configuration and status). It does not explicitly differentiate from siblings like bing_get_ads or bing_get_ad_groups, but the resource is clear enough to distinguish it.

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 'Read Performance Max asset groups' and the Performance Max scope, but the description gives no explicit when-to-use guidance, prerequisites, or alternatives versus sibling tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds one genuinely useful semantic caveat — that an empty audience does not imply it can be matched or targeted — but says nothing about pagination, rate limits, or what a read returns beyond that.

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 short sentences with the scope stated first and the caveat second. Both carry information; it is tight and front-loaded, just very sparse.

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?

An output schema exists, so return values need not be explained, and annotations plus a fully documented schema carry most of the load. Still, for a read tool over six enum branches, the description gives no sense of what configuration fields are returned or how the empty-audience caveat affects downstream decisions.

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%, with enum for type and clear docs for accountId and audienceIds, so the baseline is 3. The phrase 'one audience type' reinforces the enum scoping but adds no format or behavioral detail beyond the schema.

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

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

States a specific verb and resource: 'Read audience configuration', scoped to 'one audience type'. It is clearly distinct from sibling getters like bing_get_campaigns or bing_get_targeting, though it does not name a close alternative the way a 5 would.

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 only implied by 'Read ... for one audience type' and the schema's note that audienceIds can be omitted. There is no explicit statement of when to use this versus other audience-related calls (e.g. bing_get_targeting) or when not to.

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?

The annotations provide strong safety guarantees (readOnlyHint: true, destructiveHint: false). The description complements this by defining the scope of information retrieved (configuration, budget, settings) without repeating the explicit safety metadata.

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 two sentences are highly efficient and front-loaded. Every part of the description contributes directly to clarifying the tool's function or logic.

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

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

Given the large list of sibling tools, it clearly specifies that this function operates on 'Campaign' resources, preventing the agent from mistakenly invoking it for ad groups, keywords, or assets.

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%. While the description provides useful high-level context on the necessity of multiple calls, it adds no semantic meaning to the individual parameters beyond what the schema already specifies.

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 explicitly states the function—reading native campaign configuration, budget, settings, and status—immediately distinguishing it from other `bing_get_` tools which might handle Ads, Keywords, or Targeting.

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

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

It provides clear instructions on usage by stating, 'Repeat for other types to inventory the whole account,' which dictates the agent's operational flow for account-wide tasks.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-obvious context: that reading goal configuration does not establish that conversions are actually being recorded, which prevents a common misinterpretation. It stops short of mentioning result volume or whether goalIds is capped at 100.

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 short sentences, zero filler, with the core capability front-loaded and the interpretive caveat immediately after. Nothing could be removed without losing signal.

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?

An output schema exists and annotations cover the safety and world-access profile, so the description needn't explain return values or side effects. The only remaining gap is the lack of any note on result volume or pagination when omitting goalIds, which for a read tool capped at 100 IDs would have been worth a clause.

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%, with the type enum, the goalIds 'omit to read every goal of this type' behavior, and the BING_ADS_ACCOUNT_IDS format all documented in the schema itself. The description adds no parameter information beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Read conversion goal configuration.' An agent can distinguish this from reporting/insight siblings like bing_get_report or bing_get_insights. It does not explicitly name a sibling it should be preferred over, keeping it just short of a 5.

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 statement of when to use this tool versus alternatives, and no prerequisites (e.g. that it needs a configured UET tag or that bing_get_uet_tags should be checked first). The second sentence is an interpretation caveat about results, not usage routing, so guidance remains largely absent.

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?

While annotations cover safety (readOnlyHint, destructiveHint), the description adds unique behavioral context by stating, 'The link is returned as data and not downloaded.' This informs the agent about the expected output format.

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 text is brief, front-loaded with the primary purpose, and highly efficient. Every sentence adds necessary value without being verbose.

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

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

Given the single required parameter and the high coverage of structured data, the description provides all necessary context (how to format IDs, what the link represents, and what the link is) for correct execution.

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 covers the parameter, but the description provides essential semantic clarification: users must use the 'numeric ID' and explicitly avoid the 'eight-character account number shown in the web app.' This prevents common invocation errors.

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 explicitly states the tool's function: retrieving 'Microsoft's current geographic targeting file link.' The name and description clearly identify the resource being accessed.

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 provides critical usage rules, specifically instructing the agent to 'use its Location IDs; never reuse Google location IDs.' This acts as a direct boundary condition for its correct application.

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

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

Annotations already declare readOnlyHint/idempotentHint true and destructiveHint false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the call is asynchronous and returns a receipt rather than data, column compatibility constraints exist, and sandbox data availability may differ — all beyond what structured fields say.

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

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

Three short sentences with zero filler; the async-submit fact and the polling instruction are front-loaded where an agent will read them first.

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 9-parameter async submission tool with an output schema and 100% schema coverage, the description supplies the key missing piece — that the return is a receipt requiring polling — plus compatibility caveats. Minor gaps remain (report size limits, receipt expiry, failure modes), but nothing essential to calling it correctly is absent.

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

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

Schema description coverage is 100%, so every parameter (since/until, columns, accountId, reportType, aggregation, reportTimeZone, returnOnlyCompleteData) is already documented inline, making 3 the baseline. The description adds only the general caveat that columns must be compatible with reportType and points to bing_get_reporting_schema, without elaborating on individual parameter semantics.

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

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

States a specific verb and resource ('Submit an asynchronous Microsoft Advertising report') plus the scope ('selected account') and the return value ('a receipt'). This clearly separates it from bing_get_report, which the description names as the polling counterpart, so an agent can distinguish the two without opening either schema.

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

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

Explicitly tells the agent the follow-up step ('Poll the receipt with bing_get_report') and flags prerequisites ('Column compatibility and sandbox data availability apply'), and the schema points to bing_get_reporting_schema for valid columns. It lacks explicit when-not-to-use guidance, but the submit-then-poll workflow is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile needs no restating. The description adds the "owned" qualifier, which signals an access/permission precondition — useful context that annotations don't convey — but says nothing about volume, pagination, or whether all keywords are returned in one call.

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 front-loaded sentence with zero filler; the operation and the returned data are stated immediately. Nothing could be removed without losing information.

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

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

With an output schema present, return values need no explanation, and all four required parameters are fully documented in the schema. The remaining gap is behavioral: no statement about result volume or whether the call returns the full keyword list, which matters for a list-style read with no limit parameter.

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 every parameter carries a detailed description, including the accountId vs. account-number caveat and the campaignType enum semantics, so the schema does the heavy lifting. The description adds nothing beyond the schema — its "owned ad group" phrasing loosely maps to the required accountId/campaignId/campaignType/adGroupId chain but adds no syntax or format 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?

Specific verb+resource ("Read keywords ... from an owned ad group") and it enumerates the returned fields (match types, bids, status), so the agent knows exactly what it gets. It's implicitly distinct from siblings like bing_get_ads and bing_get_ad_groups by operating at the ad-group level, but it never names an alternative or explicitly scopes itself against them.

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?

"From an owned ad group" is the only contextual cue, hinting that the resource must be owned/accessible, but there is no when-to-use guidance, no prerequisites spelled out, and no alternatives (e.g., bing_get_ads, bing_get_targeting) referenced. The agent must infer selection from the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds only that the response includes image representations and their URLs — useful context, but an output schema exists, so this adds modest value and says nothing about behavior on invalid or missing IDs.

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 front-loaded sentence with the verb and resource first and the payload description second. No filler, though it is terse enough that the usage context is left implicit rather than stated.

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 read tool with a fully documented schema, complete annotations, and an output schema that carries return semantics, this description is sufficient to call the tool correctly. Only minor gaps remain, such as error behavior for non-existent IDs.

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 both parameters (accountId, mediaIds, including the 1-100 bound) are fully documented in the schema. The description nods to identifier-based lookup and account scoping but adds no syntax or format detail beyond what structured fields already provide, so baseline 3 applies.

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

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

States a specific verb and resource: reads metadata of uploaded media by ID within an account, and names what the payload contains (image representations and URLs). This clearly separates it from sibling readers like bing_get_videos or bing_get_ads, though it doesn't explicitly call those out.

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 rather than stated: the agent understands it needs media IDs in the selected account, but there is no explicit guidance on when to prefer this over bing_get_videos, nor any exclusions or prerequisites such as how to obtain media IDs.

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

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so safety is covered; the description adds real substance beyond them — the 2,000-row cap, that rows come back as strings, the truncation signal and how to respond to it, and a warning that empty sandbox output is not production evidence. It does not spell out what 'poll' means on a not-yet-ready report (retry vs error).

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

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

Three short sentences, each carrying distinct information: workflow dependency, result shape/limits, and a data-integrity caveat. The final caveat is slightly cryptic out of context (what 'sandbox' refers to is assumed), but nothing is padded.

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

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

An output schema exists, so return values need not be re-explained; the description nonetheless covers the row limit and truncation behavior, plus the required upstream call. Complete for correct invocation, with only the poll-not-ready semantics left implicit.

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 schema itself documents the receipt's one-hour expiry and the accountId format constraint (numeric ID, not the eight-character number). The description adds only the linkage that the receipt comes from bing_get_insights, so baseline 3 applies.

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

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

States a specific verb pair (poll and download) and resource (report), and explicitly ties it to the sibling bing_get_insights that produced the receipt. An agent can distinguish it from the other bing_get_* tools, which fetch data directly rather than poll a queued report.

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?

Clear context: use this only after bing_get_insights has submitted a report for the same account, since it requires that tool's receipt. It also gives an in-call remedy (narrow the range when truncated is true). No explicit exclusions or alternative tools are named, but the workflow gate is unambiguous.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds substantive context beyond them: the output is 'pinned' (a fixed, curated list) with 'official references', and critically it warns that listed columns may be empty, which prevents a common agent mistake (assuming availability equals data presence).

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 short sentences, front-loaded with what is returned, followed by one high-value caveat. Nothing is redundant and nothing could be cut without losing meaning.

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

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

With an output schema present and no inputs, the description only needs to convey what the resource is and how to interpret it, which it does. The omission is workflow positioning — that this is the reference to consult before calling bing_get_report — which would make it fully self-sufficient among the bing_* siblings.

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

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

The tool takes zero parameters, so the baseline is 4 and no parameter explanation is needed. The description correctly spends its words on output semantics instead of inventing inputs.

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

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

States a specific verb (read) and specific resources (pinned report types plus their native columns, with official references). This is clearly distinguishable from data-returning siblings like bing_get_report and from bing_get_write_schema, so an agent can select it without opening the schema.

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

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

The description implies the usage context (consult before choosing columns for a report) but never states it explicitly, and it does not name bing_get_report or bing_get_write_schema as the alternatives it differs from. The caveat 'a column in this list is not evidence of populated data' gives interpretive guidance, but not when-to-call guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuine context beyond them: the content is scoped to coverage, safety rules and known limitations, which tells the agent what kind of answer to expect. It omits whether the output is static or how large it is, which would matter for a doc-dump 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?

Two short sentences with no waste. The content scope comes first and the actionable directive ('read it before...') is second, so the agent gets both identity and instruction immediately.

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

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

With zero params, full annotation coverage and an output schema, the description needn't explain return values, and it doesn't. The only real gap is that it doesn't signal this is a one-time orientation read rather than something to call per-query, which would help an agent budget its calls.

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?

Zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The description correctly implies a parameterless call by describing no inputs at all.

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 noun phrase 'Coverage, safety rules and known limitations of this server' names the exact resource returned, which is enough for an agent to tell it apart from the data-fetching siblings (bing_get_campaigns, bing_get_report, etc.). It never states the verb — that it *returns* a guide document — so the agent infers the retrieval action from the title rather than the description.

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?

'Read it before claiming that a feature is or is not supported' gives an explicit trigger condition, which is the key routing signal for a documentation tool. It does not name alternatives or state when this can be skipped, but for a prerequisite doc tool the positive guidance is the part that matters.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful scope context — results include both inclusions and exclusions, and only one criterion type is returned per call — but says nothing about pagination, size of result sets, or behavior when the criterion type is unconfigured.

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, zero waste: the operation and its scope come first, followed by the single most important disambiguation. Nothing could be removed without losing information.

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

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

An output schema exists, so return values need not be described, and the description covers the essential framing: config vs performance, campaign vs ad group level, and inclusions-plus-exclusions. The only gap is routing ambiguity against bing_get_insights and bing_get_audiences, which an agent would want resolved.

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 every parameter is already documented, including the campaign-vs-ad-group distinction in adGroupId and the 'call once per type' note in criterionType. The description only echoes the one-criterion-type constraint, adding no format or validation detail beyond the schema; baseline 3 applies.

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

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

The description states a specific verb and resource ('Read configured campaign or ad group targeting'), names the scope (one criterion type, inclusions plus exclusions), and contrasts itself with performance data. It stops short of naming the sibling tool (bing_get_insights) that the performance side belongs to, so the differentiation is implied rather than explicit.

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?

'This is configuration, not demographic performance' gives a clear exclusion, which implies the agent should go elsewhere for performance data. However, it never names that alternative, and it gives no guidance on the overlap with bing_get_audiences for audience-type criteria (RemarketingList, CustomAudience, InMarketAudience all appear in criterionType).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description's 'Nothing is installed on a website' reinforces that this is a pure configuration read with no side effects, but adds little beyond what the annotations already say and gives no detail on errors, empty results, or pagination limits (maxItems 100).

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 short sentences with the purpose front-loaded and no filler. The second sentence is terse to the point of being slightly ambiguous, but it does carry real disambiguation value at minimal length.

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

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

An output schema exists so return values need not be described, and the two parameters are fully documented in the schema with complete annotations. For a simple two-parameter read tool the description is sufficient, though a note on scope (account-level vs. per-tag) would round it out.

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 both accountId and tagIds are already well documented, including the 'omit to read every tag' semantics and the warning about numeric ID vs. eight-character account number. The description adds nothing about parameters, so the baseline 3 applies.

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

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

States a specific verb and resource ('Read UET tracking tag configuration'), which is enough to distinguish it from the sibling list/report tools. It lacks explicit sibling differentiation, and the trailing sentence 'Nothing is installed on a website' is a scope clarifier rather than part of the purpose statement.

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 when-to-use guidance, no mention of alternatives among the many bing_get_* siblings, and no stated prerequisites. The only hint is the verb 'Read', which implies read-only usage but does not route the agent between this and other retrieval tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds a genuinely non-obvious domain caveat that an 'Active' status refers to media readiness rather than ad delivery, which prevents misinterpretation of results. It does not cover pagination behavior, but that is comparatively minor.

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 short sentences with no filler; the core action is stated first and the status caveat follows. 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?

The schema is fully described, an output schema exists, and annotations cover the safety profile, so the remaining burden on the description is mainly routing and scoping. It leaves the overlap with bing_get_media unresolved, which is the one thing an agent most needs clarified here.

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%, including the important accountId note about numeric IDs versus the web-app account number, and the semantics of videoIds and paging. The description adds nothing beyond what the schema already documents, so baseline 3 applies.

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

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

States a specific verb and resource: 'Read account video assets and processing status.' An agent can tell it returns video assets with a processing status. However, it never distinguishes itself from the sibling bing_get_media, which plausibly overlaps in scope.

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 statement of when to use this tool versus bing_get_media or the other asset-reading siblings, and no prerequisites or exclusions. The 'Active means...' sentence is a semantics caveat, not usage guidance, so the agent is left to infer when to pick this tool.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that only native fields are read and that account eligibility is separate, but it does not clarify what a "write schema" contains or how polymorphic objects are handled beyond pointing to external documentation.

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 short and front-loaded, with the core action stated first. The middle sentence about polymorphic object documentation is awkward and less immediately useful, but the overall structure remains efficient.

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?

An output schema exists, so the description need not explain return values, and the single parameter is fully documented in the schema. However, for a schema-retrieval tool whose name implies write-schema semantics, the description leaves the central purpose and selection criteria under-specified.

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 single entity parameter has an enum and its own description. The description adds no parameter-level meaning beyond saying the entity is a Microsoft Advertising entity, so the schema carries the parameter semantics.

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 ("Read") and resource ("pinned native fields of a Microsoft Advertising entity"), but "pinned native fields" is vague and never explains the "write schema" implied by the tool name. It does not clearly distinguish this tool from siblings such as bing_get_reporting_schema or bing_get_setup_guide.

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 when-to-use guidance, no prerequisites, and no alternatives. "Account eligibility is separate" is a scope exclusion, but it does not tell an agent when to select this tool versus other schema or entity tools.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely new context by bounding the scope of validation ('does not validate every feature'), which tells the agent not to treat a pass as a full diagnostic.

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 short sentences with no waste, and the primary action is front-loaded before the scope caveat. Slightly terse but appropriately sized for a one-parameter read tool.

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

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

With an output schema present, return values need no explanation, and a single fully documented parameter plus read-only annotations cover most of the burden. Only the routing versus sibling tools is left implicit.

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 accountId parameter is documented thoroughly in the schema (numeric ID vs eight-character number). The description adds no parameter guidance, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Read the selected account') and enumerates what is confirmed: environment, owning customer, and currency. This makes the operation concrete rather than a tautology of 'health check', though it does not explicitly distinguish itself from sibling tools like bing_list_accounts.

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 caveat 'This does not validate every feature' hints that this is a lightweight verification step, but the description never states when to prefer it over bing_list_accounts or bing_get_setup_guide. Usage is implied rather than prescribed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful non-obvious behavior: it pages through every account Microsoft returns and then keeps only the configured ones, and it lists the fields returned. Error and rate-limit behavior are not discussed, keeping this below a 5.

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

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

The description is two sentences with no repetition or filler. The scoping and filtering behavior are front-loaded, and the returned fields are summarized 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?

Given zero parameters, rich annotations, and an existing output schema, the description supplies everything an agent needs to understand the tool's scope and filtering behavior. It correctly avoids duplicating return-value documentation that the output schema already provides.

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?

This tool has zero parameters, so the baseline is 4. The schema is empty with additionalProperties=false and 100% description coverage, and the description correctly adds no parameter semantics beyond the tool-level scoping.

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

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

The description states a specific verb and resource: list the accounts reachable by this user, scoped to BING_ADS_ACCOUNT_IDS. It also names the returned fields, which makes clear this is an account-discovery tool rather than a campaign, ad group, or reporting tool.

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 'Discovery pages through every account Microsoft returns' implies this is the entry point for account discovery, but the description never explicitly states when to use it versus siblings such as bing_get_campaigns or bing_get_report. The usage context is implied rather than prescribed.

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?

While annotations cover the safety profile (readOnlyHint=true), the description adds valuable functional behavior by stating what the scan *excludes* (delivery, video contents, KPI attribution). This tells the agent precisely what information to expect and what to avoid asking for.

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 definition is extremely concise (one sentence) and every clause carries significant weight, detailing the scope of the assets and the limitations of the scan in a highly efficient manner.

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

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

Given the comprehensive input schema and the safety annotations, the description is fully complete. It provides the necessary context for a model to confidently select this tool for listing assets while managing user expectations regarding available data depth.

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 coverage is 100%, so the baseline score of 3 is appropriate. The description mentions 'parent IDs and names,' which clarifies the nature of the returned data but adds little semantic meaning to the inputs beyond what the schema already provides.

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 is highly specific, clearly stating the resource being listed ('image assets') and the context ('account-owned ads and Performance Max asset groups'). This precise focus distinguishes it well from other sibling tools like bing_get_media or bing_get_ads.

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 provides critical usage limitations by specifying a 'Bounded scan.' It explicitly warns that the tool does not return inferred delivery, video content, or KPI attribution, guiding the agent against making false assumptions about the data returned.

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