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

No annotations exist, so the description carries the full burden of behavioral disclosure. It discloses the nature of the output (diagnostic labels and recommendations) but does not explicitly state that the tool is read-only or has no side effects, nor mention prerequisites such as whether the campaign must already exist. 'Analyzes' implies non-mutation, but the absence of an explicit safety statement leaves some 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?

One compact sentence that leads with the action, lists the metrics analyzed, and specifies the diagnostic outputs. There is no filler or redundancy; every clause adds useful information.

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

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

For a low-complexity, one-parameter tool, the description covers what analysis is performed and what the output will contain (assessments and recommendations). However, with no output schema and no annotations, it could also clarify whether the raw metric values are returned and explicitly state that the operation is read-only. Still, the core information an agent needs to call and interpret the tool is present.

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 parameter campaign_id is documented as 'The campaign ID to evaluate'. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific action ('Analyzes campaign metrics') and a specific output ('diagnostic assessments' with enumerated labels like STRONG, MODERATE, NEEDS_ATTENTION, plus optimization recommendations). It distinguishes itself from sibling getters like get_campaign by emphasizing analysis and recommendations rather than raw retrieval. Minor gap: the title promises ROAS but the description never mentions revenue or ROAS.

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 explicit when-to-use or when-not-to-use guidance is provided, and no sibling alternatives are named. The wording implies use for performance evaluation and optimization planning, but an agent cannot tell from the description when to choose this over get_delivery_insights or detect_spend_anomalies.

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 burden of behavioral disclosure. It explicitly states the operation is permanent and that archived audiences cannot be restored, which is essential for a destructive action. It could add more context about downstream effects, but the core irreversibility is clearly communicated.

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 short sentences with no wasted words. The core action is front-loaded, and the critical warning about permanence is included without elaboration.

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

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

For a single-parameter destructive operation with no output schema, the description covers the essential context: what happens and the permanent consequence. It does not mention required permissions or the response format, but those are less critical given the simple action and complete schema.

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 only parameter, custom_audience_id, is documented as 'Audience ID'. The description does not add additional parameter-level meaning, but none is necessary for such a simple, well-covered 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?

The description uses a specific verb ('archive') and resource ('custom audience'), and clearly states the permanent nature of the action. This distinguishes it from sibling tools like list_custom_audiences, create_custom_audience, and mutate_audience_membership.

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 intended use case is implied by the verb 'archive' and the warning that archived audiences cannot be restored. However, there is no explicit guidance about when to choose this tool over alternatives, such as mutate_audience_membership or merge_custom_audiences.

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 behavioral disclosure burden. It reveals meaningful behavior: inspecting brand approval and event settings, and optionally polling a 15-minute live stream. It does not disclose whether the audit is read-only, what permissions are required, or any side effects, so transparency is partial rather than complete.

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 crisp sentences front-load the purpose ('Comprehensive tracking audit') before detailing the scope. There is no fluff, though 'Comprehensive' is slightly redundant with the enumerated checks that follow.

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 only one optional parameter, no output schema, and no annotations, the description provides enough for an agent to decide when to call it and how to invoke it: what is inspected, the optional live-poll behavior, and the diagnostic intent. Not stating the output/return shape is a minor gap for a diagnostic audit tool.

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

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

Schema coverage is 100%, and the schema already documents pixel_id as optional and tied to verifying the live browser event stream. The description reinforces the 15-minute stream behavior but adds no new parameter meaning beyond what the schema 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 uses a specific verb ('audits'/'inspects'), identifies the resource (conversion tracking health), and enumerates concrete checks: brand approval, conversion event settings, and live pixel stream. These specifics distinguish it from narrower siblings like inspect_recent_pixel_events and list_conversion_event_settings.

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

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

The description implies use for diagnosing missing events, tag misconfigurations, and CAPI readiness, which gives useful context. However, it never explicitly contrasts this tool with alternatives such as inspect_recent_pixel_events or list_conversion_event_settings, nor does it state when not to use it.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does reveal key behavior: deep copy, new campaign created in paused state by default, and overridable settings. However, it omits important operational details such as return value, synchronous/asynchronous behavior, source campaign preservation, and the unsupported 'flight dates' override is misleading.

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 only two sentences, with the core behavior and default state front-loaded. It is appropriately concise, but the second sentence's vague reference to 'flight dates' is both unsupported and imprecise, preventing a perfect score.

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 has 5 parameters, no annotations, and no output schema. The schema fills many gaps, but the description does not explain what the tool returns (e.g., new campaign ID), the effect of include_ads=false, or other end-state details. The misleading 'flight dates' reference further reduces completeness.

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. Yet the description adds a potentially misleading claim about overriding 'flight dates,' which has no corresponding parameter in the schema (additionalProperties is false). This actively undermines correct parameter usage, outweighing the high 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 a specific verb ('deep-copies') and resource ('existing campaign along with all its child ad groups and ads'), making the tool's function obvious. It is readily distinguishable from sibling tools like create_campaign or update_campaign.

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 through emphasis on cloning an entire hierarchy, but there is no explicit guidance on when to use this tool versus alternatives or when not to use it. It doesn't name sibling tools or provide selection criteria, so usage must be inferred.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only restates that the tool creates an ad and lists some field constraints; it does not mention idempotency, permissions, side effects, or response behavior despite having an idempotency_key parameter.

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 primary action is front-loaded and the creative-type details are compactly summarized. Every phrase 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 10-parameter creation tool with no annotations and no output schema, the description plus schema is mostly adequate for invocation. However, it leaves idempotency semantics and response shape unaddressed, so the agent must infer important behavioral details.

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 90%, so the baseline is 3. The description adds helpful context linking creative_type to target_url and file_id for chat_card, but most of this duplicates the schema's existing parameter descriptions, and idempotency_key remains unexplained.

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

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

States a specific verb and resource: 'Create an ad in an ad group', which clearly distinguishes it from sibling tools like create_ad_group or create_campaign. It also enumerates the two creative types, making the tool's exact scope 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?

Clearly indicates this is the tool for creating an individual ad within an ad group, and notes that product_ad_template is for product feed campaigns. It lacks explicit exclusions or comparisons to alternatives such as submit_bulk_mutation_job, but the 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, the description carries the burden of disclosing behavior. It usefully explains the billing event constraint and max_bid_micros units, but omits what the API returns on success, idempotency behavior, and prerequisites like campaign existence.

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 well-structured: the purpose leads, followed immediately by the two most error-prone specification details. No filler or repetition.

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

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

For a create operation with 9 parameters, no annotations, and no output schema, this description covers the most critical constraints but leaves gaps: it does not state the response shape, whether a created ad group ID is returned, or how idempotency_key behaves. It is adequate but not fully complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: billing_event_type constraints tied to campaign objective and max_bid_micros unit conversion with concrete examples. These are genuinely useful enrichments.

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: 'Create an ad group under a campaign.' This clearly identifies the action and the parent relationship, distinguishing it from tools like create_campaign or create_ad without being tautological.

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

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

It gives clear, actionable guidance: billing event must match the campaign objective, with explicit mappings for CPM, CPC, and oCPC. It does not explicitly compare against sibling create tools, so it stops short of a 5.

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 transparency burden. It adds two useful behavioral facts: the micros unit for the budget field and the immutability of bidding_type after creation. However, it does not disclose other side-effect/behavioral details such as return value, sync/asynchronous behavior, idempotency retry semantics, or permission requirements.

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 concise sentences, with the core operation first and the two most important caveats immediately following. No filler or repetition of schema content.

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 rich schema covers all parameters, defaults, required fields, and the paused-status recommendation, which compensates for much of the missing context. Still, with no annotations and no output schema, the description leaves return-value format and post-creation behavior unspecified, and doesn't mention error cases or prerequisites. Adequate for a straightforward create call, but not fully complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a concrete example for lifetime_spend_limit_micros (25000000 = $25.00) and warns that bidding_type is immutable after creation, which is not obvious from the schema's enum alone. This exceeds the baseline without re-documenting every field.

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 'Create an ad campaign' with a specific verb and resource, clearly distinguishing creation from sibling get/update/list/set/clone campaign tools. The title reinforces the operation, so an agent can select it without ambiguity.

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 creation context is implied by the verb 'Create' and the sibling list contains update/set_state/clone alternatives, but the description gives no explicit when-to-use guidance, prerequisites, or conditions favoring this tool over clone_campaign_structure or update_campaign. It relies entirely on the tool name.

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 behavioral disclosure. It usefully states that the tool defines an active conversion goal tied to a pixel source, implying a creation side effect. But it omits details such as prerequisites for the pixel source, authentication/permission needs, or what the tool returns.

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 front-loaded: the first sentence identifies the operation and object, and the second sentence gives the key use case. There is no filler or repetitive content.

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 reasonably complete given full schema coverage, but there is no output schema and no annotations. It lacks explicit information about the expected response, the need for an already-created pixel source ID, and edge-case behavior such as custom_event_name for custom event types, leaving meaningful gaps.

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 parameters are already well-documented in the schema. The description adds high-level context and examples, but no additional parameter semantics beyond what the schema already provides, 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 uses a specific verb ('Defines') and resource ('conversion goal'), with concrete examples of event types and the binding to a pixel source ID. It is clear about what the tool does, though it does not explicitly name or contrast sibling tools.

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

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

The description gives clear usage context: this tool is required for oCPC conversion-optimized campaigns, which helps an agent decide when to use it. However, it does not mention exclusions or alternative tools, so it stops short of full routing guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a useful security note ('store securely in server secrets'), indicating the key is sensitive. However, it does not mention important creation behavior such as whether the key value is shown only once, permissions required, or how the key should be managed beyond storage.

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 filler: the first states the core action and purpose, and the second adds an important operational note. It is front-loaded and 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?

Given the low complexity (one parameter, no output schema, no annotations), the description is mostly adequate: it explains what the key is for and tells the agent to store it securely. However, it is silent on the tool's return behavior, such as whether the key is returned only at creation time, which is a meaningful gap for a credential-generation tool.

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

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

The schema already fully documents the single parameter with a description and example ('Production CAPI Key'), so schema coverage is 100%. The tool description adds no additional parameter-level detail, which is acceptable but does not improve semantics beyond the baseline.

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 ('Generate') and names the resource ('server-side Conversions API key') along with its intended purpose ('send conversion events directly from backend servers'). This clearly differentiates it from client-side alternatives like create_web_pixel, though it does not explicitly name sibling tools.

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

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

The description gives clear context for when to use the tool: when conversion events need to be sent directly from backend servers. It does not list alternatives or exclusions explicitly, but the 'directly from backend servers' phrasing effectively implies the server-side use case.

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 full burden of behavioral disclosure. It does disclose the two creation paths, which is real value, but it omits significant behavioral facts: whether creation is synchronous or async (sibling get_audience_operation_status hints at operation-status tracking), what response is returned, and how file_id relates to the upload pipeline. For a mutation tool with zero annotation coverage, this disclosure is insufficient.

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, roughly 24 words, with the core purpose front-loaded and no filler. Each sentence contributes a distinct fact: the essential action and the two acceptable construction paths. It is efficient but slightly under-specified for a tool with eight parameters.

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 an 8-parameter creation tool with no annotations and no output schema, the description is too thin. It omits the return value, async behavior, the dependency on an upstream upload step, and the conditions under which identifier_type or identifier_resolution are required. The rich sibling ecosystem (mutate, merge, prepare_payload, operation_status) makes this gap more consequential.

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 63%, with name, file_id, description, identifier_type, and identifier_resolution already documented; the description adds a useful conceptual frame by tying name to the empty mode and file_id to the file mode. It does not compensate for the three parameters lacking schema descriptions (filename, mimetype, file_size), nor does it clarify when identifier fields become mandatory. Mid coverage with modest added value warrants a 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 and resource ('Creates a new custom audience') and clarifies two construction modes: an empty audience for incremental builds or one attached to an uploaded file_id. The verb+resource combination distinguishes it from create_campaign, create_ad, and create_web_pixel. However, it does not explicitly differentiate it from its audience-cluster siblings (merge_custom_audiences, mutate_audience_membership), so it stops 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 'incremental builds' phrase gives an implicit workflow context for the empty-audience mode, and the file_id option implies a prior upload step. But there is no explicit when-to-use vs. alternatives guidance, no prerequisites (e.g., must upload first to obtain a file_id), and no exclusions. 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 present, the description carries the burden and does disclose the core effect (creation), the returned IDs (clidsrc_*, pixel_id), and automatic advanced matching. It does not cover permissions, idempotency, immediate usability of the pixel, or any side effects beyond creation, so it is adequate but not rich.

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

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

A single imperative sentence that front-loads the action and return values; the advanced-matching clause is relevant and not padding.

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

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

For a one-parameter creation tool, it clearly states the input (name via schema), the side effect, and the key returned values, even without an output schema. It does not document response shape or next-step usage, but the essential information for invoking the tool is present.

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 covers the name parameter 100%, including a descriptive example, so the description does not need to compensate. It adds no additional meaning for the name parameter beyond what the schema already gives.

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 resource ('web pixel'/'web conversion source') and action ('creates'), and specifies the two returned identifiers, which separates it from sibling conversion-tracking tools. The additional automatic advanced matching behavior adds context beyond the title.

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 on when to choose this over sibling conversion-tracking tools such as create_conversion_api_key, create_conversion_event_setting, or inspect_recent_pixel_events. There are no prerequisites, exclusions, or alternative conditions mentioned.

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?

Since no annotations are provided, the description carries the full behavioral burden. 'Scans' and 'recommends' convey that the tool analyzes and advises rather than mutating campaigns, and the list of detected conditions tells the agent what signals drive the tool. It stops short of explicitly declaring read-only status or describing response shape, but the non-mutating intent is clear.

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 first front-loads what is scanned and the anomaly categories, the second states the recommendation-oriented output. The detail in the anomaly list earns its place by clarifying detection semantics.

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?

All four parameters are optional and self-documenting, so the description covers the invocation trigger without repeating schema details. Since there is no output schema, the note that it recommends remediation actions gives a reasonable expectation of the return value, though a precise output structure is not specified. This is adequate but not exhaustive.

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 parameters are already individually documented with defaults and ranges. The description adds no new parameter-level information but reinforces semantic context through the anomaly types it mentions. The baseline of 3 is appropriate because the schema does the heavy lifting.

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 names the resource (delivery and conversion metrics across campaigns) and the specific verbs (scans, detects, recommends), then enumerates concrete anomaly types: runaway spend, zero-conversion budget drain, low-CTR creative burnout, and abnormal CPA spikes. This makes it clearly distinct from generic metrics or analysis siblings like get_delivery_insights and analyze_campaign_performance.

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 text establishes a clear guardrail use case: use this when you need to identify spend/CPA anomalies and get recommended remediation actions, not merely raw metrics. It does not explicitly name alternatives or state when not to use it, but the intended context is clear enough to route an agent correctly.

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 of behavioral disclosure. It states that the tool 'generates' outputs, but it does not clarify side effects, output format, whether any ad objects are created, or other behavioral traits such as response structure or limits beyond what the schema captures.

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 is inforive and front-loaded with the core action. It avoids unnecessary filler, though it slightly overlaps with the title and could more explicitly mention output details.

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

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

The tool has 7 parameters and no output schema or annotations, so the description needs to carry more contextual weight. It communicates the main purpose and inputs but does not describe the return structure, the shape of the generated copy, or the absence of ad-object mutations, leaving some ambiguity for the agent.

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 adds little beyond echoing 'product, audience, and value propositions,' which maps to product_name, target_audience, and key_benefits. It does not add new meaning for parameters like num_queries or competitors_or_alternatives.

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 a specific verb ('Generates') and resource ('ChatGPT user queries and conversational sponsored ad copy'), and it states the tailoring inputs. It is easily distinguished from sibling CRUD operations like create_campaign or create_ad because no other sibling provides generation-style output.

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 this tool: when realistic high-intent queries or conversational ad copy are needed for a product, audience, and value propositions. However, it does not explicitly state when not to use it or how it relates to alternatives like create_ad, leaving some routing decisions to inference.

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

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

With no annotations provided, the description carries the full behavioral burden. 'Fetch' implies a read-only operation and the included output fields are listed, but the description does not disclose error behavior, authorization requirements, or any other operational traits.

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

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

The description is a single sentence that front-loads the core action and resource, then adds only the key output details. There is no wasted wording.

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 one-parameter get-by-ID operation, the description and schema together provide enough to invoke it correctly: the resource, the identifier, and the included output fields. It would be slightly more complete if it mentioned not-found or error behavior, but that is not critical for a basic fetch.

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 ad_id parameter is already well described with a concrete example. The tool description adds no additional meaning about the parameter itself.

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 the specific verb 'Fetch' with the resource 'ad' and the retrieval key 'by ID', and it adds the meaningful detail that creative details and review_status are included. This clearly distinguishes it from sibling tools like list_ads or get_campaign.

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 'by ID' clearly indicates this is the single-resource lookup tool, implying it should be used when an ad_id is known and a single ad's details are needed. However, it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations, the description carries the behavioral burden. 'Fetches' clearly signals a read-only operation, and the listed return fields provide concrete expectations. It does not discuss error cases or rate limits, but for a simple getter these omissions are 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?

The description is a single, tight sentence that front-loads the action and resource, then enumerates the returned metadata fields. There is no redundant detail 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?

This is a low-complexity, zero-parameter tool with no output schema. The description covers what the tool returns and how the account is identified, which is sufficient for an agent to select and invoke it 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 tool takes zero parameters, so there is no parameter semantics for the description to add. The baseline of 4 applies because nothing is missing on this front.

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 a specific verb ('Fetches'), a resource ('the OpenAI Ads account'), and the scope ('associated with the configured API key'). It is distinct from sibling tools like update_ad_account_brand, though it does not explicitly name or contrast itself with any sibling.

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: use this tool when you need the ad account metadata for the configured API key. There is no explicit when-to-use or when-not-to-use guidance, but with zero parameters and a unique resource, the intended context is reasonably 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, the description carries the burden of disclosing behavior. 'Fetch' conveys a read-only lookup, but the description does not mention error handling, return value structure, pagination, or potential absence of the ad group. It is not misleading, but it is minimal.

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, directly worded sentence carries the entire description with zero filler. The core action and target are front-loaded, making it easy for an agent to parse quickly.

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 get-by-ID tool with one fully documented parameter and no output schema, the description is nearly sufficient. The only notable gaps are lack of explicit return-value or error behavior, but these are less critical for a straightforward read operation.

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% for the single parameter ad_group_id, including a type and example. The description's 'by its ID' merely paraphrases what the schema already states, adding no new semantic information. Baseline 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 ('Fetch'), a specific resource ('ad group'), and the selection criterion ('by its ID'). This clearly distinguishes it from list_ad_groups (collection fetch) and get_campaign/get_ad (different resources).

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 'by its ID' implies this tool should be used when the agent has a specific ad group ID and needs a single ad group, rather than listing all ad groups. However, it does not explicitly name alternatives or state when not to use the tool, so it stops short of full 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does convey the asynchronous, polling-oriented nature and the terminal states 'succeeded' or 'failed'. However, it does not mention polling behavior such as rate limits, timeouts, or behavior for invalid operation IDs, nor does it describe the response content beyond indicating status.

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 constructed sentence with no filler. The core action, the resource, and the stopping condition are all front-loaded, and every word contributes value.

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 polling tool with a clear schema and no output schema, the description is largely complete. It explains the purpose, the asynchronous nature, and the terminal states. A minor gap is the lack of polling-interval or backoff guidance, but the core context needed to select and invoke the tool is present.

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 required parameters. The description adds no additional parameter-level meaning beyond what the schema provides, 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 verb ('Poll'), a specific resource ('status of an asynchronous membership operation'), and enumerates the operation types ('add, remove, replace, merge'). This clearly distinguishes it from sibling tools like get_bulk_mutation_job_status, which targets bulk mutation jobs rather than individual audience membership operations.

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 clear context: it is for polling an asynchronous membership operation until a terminal state is reached. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5, but the polling intent and completion criteria are unmistakable.

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 for behavioral disclosure. The terms 'Poll' and 'inspect' indicate a read-only operation, and the explicit list of possible job states gives useful insight into the response semantics. It does not explicitly state non-destructiveness or mention polling frequency, but the verb choice makes the read-only nature clear.

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 core action (poll progress) and then adds the per-operation inspection detail. There is no repetitive or filler content.

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 essential purpose and behavior for a polling tool, and the schema fully documents the four parameters. It could be slightly more complete by explicitly saying to use it after submit_bulk_mutation_job and noting that operation results are paginated via after/limit, but these are inferable from the sibling list and schema.

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 parameters are already well documented in the input schema. The description adds slight context by linking 'per-operation execution results' to the include_operations parameter, but it does not meaningfully extend parameter understanding 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?

The description clearly states the tool's purpose with specific verbs ('Poll', 'inspect') and identifies the resource ('bulk job progress', 'per-operation execution results'). It is readily distinguishable from siblings like submit_bulk_mutation_job, which creates jobs rather than checking their status.

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 after submitting a bulk mutation job, and the polling language suggests repeated checks. However, there is no explicit 'use this when...' guidance or mention of when not to use it, such as pointing to get_audience_operation_status for non-bulk operation checks.

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 behavioral burden, and 'Fetch' unambiguously signals a read-only operation with no mutation. It does not disclose error behavior or auth requirements, but for a simple get-by-ID tool the core behavior is 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?

The description is a single front-loaded sentence with no filler. Every word adds meaning, and it is appropriately sized for the tool's simplicity.

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, no-nested-object getter with no output schema, the description plus schema is nearly complete. It lacks explicit return/error details, but 'fetch a campaign' reasonably implies returning the campaign object.

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

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

Schema description coverage is 100%, so the schema already documents campaign_id with an example. The description adds only that the campaign is fetched by its ID, aligning with but not enriching the schema's parameter meaning.

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

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

The description states a specific verb ('Fetch'), a specific resource ('OpenAI Ads campaign'), and the scope ('single ... by its ID'). This clearly distinguishes it from sibling tools like list_campaigns or update_campaign.

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 'single ... by its ID' establishes a clear usage condition: use this when you need exactly one campaign and have its ID. It does not explicitly name alternatives like list_campaigns for bulk needs, so it stops short of full when-not guidance.

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

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

With no annotations available, the description carries the behavioral disclosure burden and adds two useful facts: conversions always equals click_through_conversions, and view-through conversions use a fixed 1-day impression window. However, it does not disclose response shape, pagination, or date-range limits, leaving some behavioral gaps.

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 action and metrics are front-loaded, and the extra behavioral notes earn their place. Nothing is redundant.

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 reporting call the core semantics are present, but with no output schema and no annotations, the absence of any mention of response format or time-range constraints is a noticeable gap. The description is adequate but would benefit from one or two sentences on output structure or filtering behavior.

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 100% of parameters, establishing a baseline of 3. The description's caveats clarify the returned metrics but do not add parameter-level detail beyond the schema, such as how aggregation_level or entity_ids affect the result.

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 ('Retrieve') and names the exact resource ('attributed conversion totals') along with the three metric fields returned. It is clear and not a tautology, though it does not explicitly name or contrast sibling tools such as get_delivery_insights.

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 about when to use this tool over alternatives like get_delivery_insights or analyze_campaign_performance. The description focuses on metric semantics rather than providing invocation context, prerequisites, or exclusions.

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

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

With no annotations present, the description carries the behavioral disclosure burden. It usefully discloses that size is returned only as privacy-preserving ranges rather than exact counts, and that membership_revision is part of the response. It does not cover error cases or authentication, but the read-only nature is clear from the name and retrieval framing.

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 no filler. The most important behavioral detail (privacy-preserving size ranges) is front-loaded and examples clarify the expected format.

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 one-parameter getter with no output schema, the description covers the key return fields the agent needs to interpret the result. It is sufficiently complete for invoking the tool, though it does not describe not-found or error responses.

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 fully documents the single custom_audience_id parameter and its caud_* format, so the description adds little parameter-level meaning. Baseline 3 is appropriate given 100% schema description 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 names a specific verb ('Retrieve') and resource ('audience') and enumerates the exact data returned: status, privacy-preserving size ranges, and membership_revision. This clearly distinguishes it from related list/create/mutate audience tools.

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

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

The intended usage is implied by the verb 'Retrieve' and the single ID parameter, but no explicit guidance is given about when to choose this over list_custom_audiences or get_audience_operation_status. There is no mention of alternatives 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 provided, the description carries the full behavioral burden. The read-oriented verb 'Retrieve' and the note that results include 'zero-impression items' disclose real behavior, but pagination behavior, rate limits, and output characteristics beyond the metric list are left unstated.

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

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

Two sentences with the core purpose front-loaded and no filler. The second sentence is a dense list of supported options, but every item earns its place given the tool's complexity.

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 10 parameters, no annotations, and no output schema, the description covers purpose and key options while the schema handles parameter documentation. However, it omits when to use this over get_conversion_insights and gives no return-structure context beyond the metric names, which is a notable gap for an analytics query tool.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents all 10 parameters thoroughly. The description mostly restates enum values the schema already provides (aggregation_level, time_granularity, segments), adding little new parameter meaning beyond confirming the default metric set.

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

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

The description opens with a specific verb and resource: 'Retrieve advertising performance metrics (impressions, clicks, spend, CTR, CPC, CPM)', which clearly identifies what the tool does. The tool name and listed delivery metrics separate it from the sibling get_conversion_insights, but the description never explicitly names that alternative, so it stops short of full sibling 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 enumerates supported options (aggregation_level, time_granularity, segments, zero-impression items) but gives no guidance on when to choose this tool over alternatives. There is no mention of get_conversion_insights or any when-to-use/when-not-to-use condition, leaving tool selection entirely to inference.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It usefully discloses the 50-event cap, the 15-minute window, and the event source ('received by OpenAI from the JavaScript pixel SDK'), which gives the agent realistic expectations about scope and recency limits.

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

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

The description is two sentences with no filler. The primary purpose is front-loaded, and every sentence adds operational value, including the response limit and time window.

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

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

For a single-parameter, read-only inspection tool, the description covers the essential invocation context: what events are returned, how many, and from what time window. It does not describe the exact structure of the raw events, but with no output schema, the phrase 'raw events' plus the source and recency window is reasonably complete for a low-complexity tool.

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

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

Schema description coverage is 100%, and the pixel_id parameter is already documented as coming from create_web_pixel. The description does not add additional parameter-level meaning, but it does not need to since the schema already provides sufficient context. 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?

Description states a specific action ('test and verify') on a clear resource ('incoming browser pixel events') and explicitly says it returns raw events. It is clear, though it does not explicitly distinguish itself from related sibling tools like send_test_conversion_event.

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 wording 'test and verify incoming browser pixel events' implies the tool is used for validating pixel integration, but it does not explicitly state when to use it versus alternatives or when not to use it. The usage context is inferable but not spelled out.

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 full burden of behavioral disclosure. It only says 'List' and implies a read operation; it does not mention pagination behavior, ordering, default limits, or what happens when no ad groups exist. This is a minimal disclosure.

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 one short sentence with no wasted words. The action and primary scope are front-loaded, making it easy for an agent to parse quickly.

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

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

There is no output schema and no annotations, so more explanatory weight falls on the description. The description correctly identifies the input scope but does not address return format, pagination behavior, or parameter semantics, leaving an agent under-equipped for a correct invocation beyond the required campaign_id.

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 75%, so it is not high enough to earn the baseline 3. The description only restates the campaign_id concept already in the schema and adds no meaning about the 'after' cursor, 'limit', or 'order' parameters beyond what the schema 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 uses a specific verb ('List'), identifies the resource ('ad groups'), and scopes it to a parent campaign ID. This clearly distinguishes it from sibling tools like get_ad_group (singular retrieval) and list_campaigns (different resource).

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 context: call this when you need ad groups for a specific campaign. However, it does not mention alternative tools or state when not to use it, leaving the routing decision partially to inference.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure, but it only restates the listing action. It does not disclose pagination semantics hinted at by the 'after' cursor and 'limit' parameters, ordering defaults, or error behavior. Nothing is contradicted to the level of a score of 1, but the disclosure is minimal.

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 single sentence is efficient with zero fluff and front-loads the core action. However, it errs toward under-specification rather than genuine conciseness: a 4-parameter tool with a pagination cursor and enum receives no behavioral elaboration beyond six 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?

Incomplete for an agent. With no output schema and no annotations, the description should explain cursor-based pagination ('after', 'limit' capped at 500), ordering behavior, and the expected response shape — none of which are addressed. It does establish the required ad_group_id scope, which prevents misuse of the one required 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 description coverage is only 25% (ad_group_id alone has a description). The description adds marginal meaning by clarifying the scope, but it fails to compensate for the undocumented 'after', 'limit', and 'order' parameters, leaving their semantics entirely to inference from parameter names.

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 ('List'), a resource ('ads'), and a scoping constraint ('specific ad group ID'), which is clear and unambiguous. It differentiates from siblings like list_ad_groups (different resource) and get_ad (single-object fetch), though the differentiation is implicit rather than explicitly named.

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 provided on when to use this tool versus alternatives. It does not mention that get_ad serves single-object retrieval, that set_ad_state handles mutations, or any conditions under which list_ads is the appropriate choice.

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 full behavioral burden. 'List' implies a read-only operation and 'with pagination' discloses how results are returned, but no output format, rate limits, or side-effect notes are provided. Adequate but minimal.

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 no filler. It states the operation, scope, and pagination behavior 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 simple read-only list tool, the description plus a fully documented schema covers core invocation needs. The lack of an output schema means the return shape is not disclosed, and no sibling routing is provided, but these are minor gaps given the 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 description coverage is 100%, with all four parameters (after, limit, order, before) already described. The description adds no parameter-specific meaning, so the baseline score 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 clearly states the tool lists campaigns in the current OpenAI Ads account and explicitly mentions pagination. This distinguishes it from sibling tools like get_campaign (singular retrieval) and create_campaign/update_campaign (mutations).

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 use case is implied by the verb 'list' and the scope 'current account', but no explicit alternatives or exclusions are given. An agent must infer when to choose this over get_campaign or other campaign 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?

No annotations are provided, so the description carries the full behavioral burden. It communicates a read-only list operation and the account scope, but it does not disclose pagination, result format, or that 'after' and 'limit' mean the response may not actually contain all definitions at once; the word 'all' may therefore mislead.

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 starting with the verb, front-loading the core purpose with no filler or redundancy. It is appropriately concise for a simple list 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?

A basic invocation is possible since there are no required parameters and the description names the resource and scope. However, with no output schema and no parameter documentation, the agent cannot reliably know the response shape or how to paginate through results, so the definition is only minimally complete.

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

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

Schema description coverage is 0%, and the description adds no meaning for the two parameters 'after' and 'limit'. The schema only provides names and types, leaving 'after' completely ambiguous and giving no guidance on how pagination works.

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 ('List'), a clear resource ('conversion definitions'), and a clear scope ('current ad account'). It clearly differentiates this from sibling tools like create_conversion_event_setting or audit_conversion_tracking by indicating enumeration rather than creation or auditing.

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 the tool: when you need to see all conversion definitions for the current ad account. However, it does not explicitly mention alternatives, exclusions, or when another tool such as audit_conversion_tracking or create_conversion_event_setting would be more appropriate.

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 burden of behavioral disclosure. It clarifies that the operation lists audiences for the current ad account and that intended_use filters eligible audiences, but it omits important behaviors such as pagination, default limits, whether archived or deleted audiences appear, and response shape.

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 filler, front-loading the core action and scope before adding a compact parameter tip. Every phrase contributes meaning, making this an appropriately sized, well-structured definition.

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 list tool with three optional parameters, the description gives a workable baseline, but it is not fully complete. There is no output schema, so return format is not clarified, and behavioral details like limits and pagination are absent, meaning an agent may still guess at some invocation details.

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 documents intended_use and custom_audience_ids, and the description adds a useful clarification that intended_use filters only eligible audiences. However, the 'limit' parameter is undocumented in both schema and description, and the description does not explain how custom_audience_ids interacts with the list operation.

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 ('List') and a clear resource ('custom audiences for the current ad account'), so an agent can tell this is a read/list operation scoped to the active account. It does not explicitly contrast itself with sibling tools like get_custom_audience, so it stops just short of full sibling 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?

There is no guidance on when to use this tool versus siblings such as get_custom_audience, create_custom_audience, or merge_custom_audiences. The only usage note is about filtering by intended_use, which is parameter-level advice rather than tool-selection 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?

With no annotations, the description carries the full burden. It discloses meaningful behavioral traits: the operation requires prerequisites ('existing, ready audiences'), is scoped to a single ad account, and creates a new union audience rather than modifying inputs. However, it does not mention whether the operation is asynchronous, what it returns, or how failures surface—gaps that matter given there is no output schema.

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 element—input count, input state, account scope, and output type—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 tool has no output schema, so the description must convey return behavior, but it only says the result is a 'new union audience' without indicating whether an ID or operation status is returned. Given the sibling get_audience_operation_status and submit_bulk_mutation_job tools, the missing async/polling guidance is a significant gap for correct invocation.

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

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

Schema coverage is 67% with idempotency_key undocumented in both schema and description. The description adds useful semantics beyond the schema by clarifying the 'union' nature of the merge and reiterating the 'ready' precondition. Yet it does not explain the role of idempotency_key, leaving that parameter under-specified.

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

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

The description states a specific verb ('Merges'), a precise resource ('existing, ready audiences'), and the exact output ('a new union audience'). The constraints '2 to 64' and 'in the same ad account' further differentiate it from sibling tools like create_custom_audience or mutate_audience_membership.

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 context is implied through 'existing, ready audiences' and 'same ad account', but the description does not explicitly say when to use this tool over alternatives, e.g., create_custom_audience or submit_bulk_mutation_job. No when-not-to-use guidance is provided.

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 full behavioral burden. It clearly communicates mutation ('Add or remove'), asynchronous execution ('Returns an asynchronous operation ID'), and audience scope ('existing custom audience'). It does not disclose rate limits, file size limits, required permissions, or whether identifiers are deleted from the audience on remove vs the whole audience being detached. The async disclosure is the main useful behavioral detail.

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

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

Two sentences: the first states the action and the two input modes; the second states the return type. Every word earns its place, and the most decision-relevant detail (whether this is a mutation and how it behaves) is front-loaded.

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 tool's purpose and async return signal, which are the essentials. However, with no output schema and no annotations, an agent cannot tell how long the operation takes, whether nested objects appear in the response, or what happens if both file_id and identifiers are provided. For a six-parameter mutation tool, it is sufficient but not rich enough to be fully self-contained.

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 all six parameters, including enum values and the 10,000-item inline limit. The description adds the distinction between inline and file-based input and the async response, but it adds no meaning beyond what the schema gives for identifiers vs file_id. Baseline 3 is appropriate because the schema does the heavy lifting.

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 ('Add or remove'), a specific resource ('customer identifiers from an existing custom audience'), and the two input modes ('inline identifiers or an uploaded file_id'). It matches the tool name and title cleanly and distinguishes it from audience creation or merging siblings.

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

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

The description implies the core use case by naming the operation and mentions 'Returns an asynchronous operation ID,' which signals that callers should poll a status endpoint. It does not explicitly say when to use this versus get_audience_operation_status or prepare_custom_audience_payload, and it does not state that file_id or identifiers is mutually exclusive. Usage context is adequate but not fully explicit.

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 description discloses meaningful behavioral details beyond basic operation: emails are trimmed and lowercased, phones are normalized to E.164, hashing uses SHA-256, and uploading is optional. With no annotations available, this is a strong attempt to describe side effects and transformations, though it does not cover all consequences such as removal behavior or return values.

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 tightly written sentences with the core transformation front-loaded and the conditional side-effect clearly stated afterward. There is 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?

The description provides the essential transformation and optional upload capability, which is adequate for a moderately complex tool. However, with no output schema and no annotations, it omits return behavior and explicit selection criteria relative to overlapping siblings, leaving some context for the agent to infer.

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 normalization behavior and optional upload, but it adds little semantic meaning beyond what the input schema already documents for each parameter.

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 operation: normalizing raw emails and phone numbers into SHA-256 hashes, with optional direct upload to a custom audience. This clearly identifies the tool's resource and action, though it doesn't explicitly differentiate itself from sibling tools like mutate_audience_membership.

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 provided about when to use this tool versus alternatives such as mutate_audience_membership or other custom-audience tools. The optional upload behavior creates overlap with mutation tools, but the description never says use this for raw PII or use mutate_audience_membership for already-hashed members.

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 full behavioral burden. It discloses the 24-hour temporary nature and that the ad must already exist, which is useful. However, it does not explain side effects, URL properties (e.g., public accessibility, expiration behavior), or whether generating a preview affects the ad's state.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the action, the resource, the temporal constraint, and the target object in a compact and readable format.

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 one-parameter tool with no output schema, the description is mostly adequate, but it omits details about the return format (e.g., a plain URL string vs. an object with a URL field) and any constraints around preview validity. The 24-hour expiry is stated, but other practical behaviors are missing.

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

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

The schema only says 'Ad ID' for the ad_id parameter, so the description adds meaningful context by specifying the ad must be an existing one. This helps the agent understand that ad_id should reference an already-created ad, not a draft or placeholder.

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 ('Generate') and a clear resource ('24-hour temporary web preview URL for an existing ad'), making the tool's function immediately obvious. It is clearly distinct from sibling tools like get_ad or create_ad, and the temporary nature adds a key differentiator.

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 implies when to use the tool: when a temporary web preview URL for an existing ad is needed. It does not explicitly name alternatives, but the context is strong enough that an agent can infer this is the correct tool for previewing; the 'existing ad' qualifier provides a light exclusion hint.

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 full burden for behavioral disclosure. It states the search behavior and output purpose but does not disclose rate limits, pagination, result structure, or whether results are limited to only targetable locations 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?

A single, focused sentence states what the tool does and why it is used, with no wasted wording. The key concepts are front-loaded and immediately actionable.

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 two-parameter read-search tool, the description adequately covers the main purpose and expected output (location IDs). The lack of an output schema is partially mitigated by the mention of location IDs, though explicit return structure details would make it fully complete.

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

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

Schema description coverage is 100%, with both 'query' and 'limit' already documented with types, constraints, examples, and defaults. The description adds the campaign-targeting context but no additional parameter-level meaning beyond what the schema 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 uses a specific verb ('search') and a specific resource ('targetable locations'), and clarifies the exact purpose: obtaining location IDs for campaign targeting. It clearly distinguishes this tool from the campaign, audience, and ad management siblings.

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

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

The description provides a clear use case: use this tool when you need location IDs for campaign targeting by keyword query. It doesn't explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to decide when to select 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 disclosure burden. It usefully reveals automatic SHA-256 hashing of emails/phones and deduplication token attachment, and it notes both test and live dispatch. However, it does not disclose authentication needs, response behavior, failure modes, or whether test events are actually stored or counted.

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 filler. The action, event examples, and key automatic behaviors are front-loaded, making it easy to scan and immediately useful.

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?

This is an external write action with 9 parameters, no annotations, and no output schema, so the agent needs more context about prerequisites and expected results. The description explains what happens to the inputs but not what the tool returns, whether setup is required first, or how failures are surfaced.

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 each parameter is already documented in the schema. The description adds some meaningful context around hashing and deduplication that relates to user_email, user_phone, and event_id, but it largely restates what the schema already says.

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 (dispatches a server-side conversion event) with concrete examples and a clear scope qualifier ('test or live'). It is easily distinguished from sibling conversion-management tools, none of which actually send conversion events.

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 core use case is clearly implied: use this when you need to send a conversion event. However, it never explicitly names alternatives or prerequisites, such as needing a Conversions API key or settings configured via sibling tools like create_conversions_api_key or create_conversion_event_setting.

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 description discloses that archiving is irreversible, which is a critical behavioral warning beyond the schema. No annotations are provided, so the description carries more weight, but it does not mention other potential behaviors such as state validation, idempotency, or whether the operation is synchronous.

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 exceptionally concise: two short sentences with no wasted words. The primary purpose is front-loaded, and the irreversibility warning earns its place as essential behavioral context.

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 two-parameter tool, the description captures the essential purpose and the most important caveat (irreversibility of archiving). It could be more complete by explicitly distinguishing from related state-setting tools, but the low complexity and clear schema limit the risk of misuse.

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 description restates and semantically confirms the action enum values ('activate, pause, or archive'), which adds some meaning to the action parameter. However, the ad_group_id parameter is only minimally described in the schema as 'Ad group ID', and the description does not offer any additional practical guidance on obtaining or formatting it.

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 specific resource ('ad group') and the three possible actions: activate, pause, or archive. This distinguishes it from sibling tools like set_ad_state and set_campaign_state by explicitly naming the target resource.

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 the tool: whenever an ad group needs to be activated, paused, or archived. However, it does not explicitly mention alternatives or state when not to use this tool versus sibling tools like set_ad_state or set_campaign_state.

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 behavioral transparency burden. It usefully discloses that archiving is permanent, which is important for a mutation operation. However, it does not mention permissions, side effects, reversibility of activate/pause, or what happens after the action.

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

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

Two short sentences with no filler. The actions are front-loaded, and the critical permanence warning is placed prominently. 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 tool is simple, and the core action is clear from the enum and description. However, without annotations or an output schema, the description leaves gaps: it does not specify how to obtain ad_id, whether any permissions are required, or any follow-up behavior. The permanence warning helps, but overall the description is minimal.

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 only 50%: ad_id's description is just 'Ad ID,' and the action property has no description. The tool description mostly restates the enum values ('activate, pause, or archive') and adds a permanence note, but it does not clarify ad_id semantics or provide meaningful detail beyond the schema. It does not sufficiently compensate for the coverage gap.

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

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

The description clearly states the verb and resource: 'Activate, pause, or archive an ad.' The resource is explicitly 'an ad,' which helps distinguish it from sibling tools like set_campaign_state and set_ad_group_state. However, it does not explicitly contrast itself with those siblings.

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

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 set_campaign_state or set_ad_group_state. It also does not clarify when each action (activate vs. pause vs. archive) is appropriate. The permanence warning is a caveat, not usage 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?

No annotations are provided, so the description carries the behavioral burden. It does disclose the important irreversible nature of archiving, which is valuable. However, it does not mention permissions, side effects of activate/pause, idempotency, or what happens on success, so coverage is partial.

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 short sentences with no filler. The core actions are front-loaded, and the critical irreversible warning is placed immediately after, making the most important information easy to process quickly.

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 low complexity of the tool and complete schema, the description is workable, but gaps remain. It lacks explicit usage guidance relative to update_campaign and other sibling tools, and it does not cover behavior beyond the irreversible archive warning, which leaves an agent to infer some operational details.

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 structured schema already documents both parameters. The description mostly restates the enum values and adds the irreversibility note, but it does not provide additional parameter-level detail such as ID format or behavior per action beyond what the schema already conveys.

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 (activate/pause/archive) and a specific resource (campaign), and clearly distinguishes this from sibling tools by naming the campaign entity and the state-transition actions. The title and description are consistent and unambiguous.

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 tool's purpose implies when it should be used, and sibling names like set_ad_state and set_ad_group_state help indicate scope, but the description does not explicitly say when to use this instead of update_campaign or other campaign-related tools. There is no when-not-to-use guidance or alternative routing.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the operation is asynchronous and mentions entity linking via idempotency keys, which is useful. However, it does not describe expected job result, polling/status-checking behavior, side effects, or error behavior.

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 behavioral trait (asynchronous bulk submission) and key parameters are front-loaded. Every clause adds useful information.

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

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

For a complex async bulk mutation tool with no output schema and no annotations, the description gives enough to invoke correctly but omits what the response looks like and how to track the job. The schema covers parameters, but the missing status/return guidance leaves a meaningful gap.

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 provides 100% parameter coverage, establishing a baseline of 3. The description adds extra meaning by explaining that entities can be linked via campaign_idempotency_key and ad_group_idempotency_key, which is not explicitly in the schema properties and clarifies how operations relate.

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 ('submits') and resource ('asynchronous bulk job') and specifies the exact operation types and the 1,000-operation limit. It clearly distinguishes itself from sibling tools like get_bulk_mutation_job_status and individual create/update endpoints.

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 use for bulk operations by noting the asynchronous job nature and the up-to-1,000-operation capacity. However, it does not explicitly say when to prefer this over individual mutation tools, nor does it name alternatives 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 provided, the description carries the burden of behavioral disclosure. It does disclose an important side effect: triggering an automatic brand review required for ad serving. However, it does not explain whether updates are reversible, how long review takes, or what happens if both parameters are provided or neither is provided.

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 front-loads the action and includes only essential information. Every clause earns its place, and the consequence is stated without 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 low-complexity, two-parameter mutation tool, the description covers what it changes and the key downstream consequence (brand review). It is slightly incomplete in that no return behavior or explicit guidance for an empty update call is given, but the schema and description together are sufficient for most calling 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 coverage is 100%, so the parameters are already fully documented in the input schema. The description adds only the account-level context that updating these fields triggers brand review, not new 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 uses a specific verb ('Updates') and names the exact resource and fields ('ad account display name', 'brand favicon file_id'), plus a distinctive consequence (automatic brand review). This clearly separates it from sibling tools like update_campaign or get_ad_account.

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 is evident that this tool is for changing ad account brand metadata, and the brand-review consequence sets expectations for when it should be used. It does not explicitly list when not to use it or name alternatives, but no direct sibling tool competes for this operation.

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 reveals only that this is a mutating operation; it does not disclose whether unspecified fields are preserved or reset, whether changes are reversible, or whether any authorization or rate-limit conditions apply. For a write operation, this is a significant 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 compact single sentence, front-loaded with the verb and resource, and every listed item is relevant. However, the misleading 'bidding_config' term and the omission of required parameters reduce the structural value; it is concise but slightly inaccurate.

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 7 parameters, no annotations, and no output schema, this description leaves out essentials: whether this is a partial update, that ad_group_id is required, what the two bidding-related fields actually do, and how this relates to set_ad_group_state. An agent would need to inspect the schema and sibling tools to safely invoke it.

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 only 43%, so the description needs to compensate, but it only partially does. It maps name, description, context_hints, and status to their intent, yet it refers to 'bidding_config' while the schema actually exposes max_bid_micros and billing_event_type, and it omits ad_group_id entirely. This introduces ambiguity instead of clarifying the bidding parameter group.

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 ('Update'), resource ('ad group'), and enumerates fields, making it clear this is a mutation tool for ad groups rather than campaigns or ads. However, it doesn't differentiate from the sibling set_ad_group_state, which also handles status changes, and the phrase 'bidding_config' doesn't match any actual schema property.

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 versus similar siblings like set_ad_group_state or update_campaign. The description only lists updatable fields and never mentions partial-update behavior, prerequisites, or alternatives. The agent is left to infer usage from the tool name and schema.

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 exist, so the description must carry the behavioral disclosure burden. It does disclose one important limitation (bidding_type cannot be updated), but it does not mention whether updates are partial, whether changes require elevated permissions, whether they are reversible, or what the operation returns. For a mutation tool this is a significant transparency 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?

Two compact sentences provide the core purpose and a notable caveat with no filler. The most important information is front-loaded and every phrase 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?

Given the simple, flat schema and full parameter descriptions, the description is minimally viable. It states what can be updated and one thing that cannot. Still, it omits sibling-tool routing and any return/response or permission context, leaving the agent to infer those from elsewhere.

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?

Because schema description coverage is 100%, the baseline is 3. The description adds value by grouping the seven parameters into intuitive categories (budget, schedule, status, description) and explicitly warning about bidding_type, which is not present in the schema. This helps an agent map high-level update intent to specific fields.

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 clear verb-resource pair, 'Update campaign,' and enumerates the updatable fields: budget, schedule, status, or description. It also highlights that bidding_type cannot be updated, which sharpens its scope. However, it doesn't explicitly distinguish itself from the closely-related set_campaign_state sibling, so it doesn't reach the top score.

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 the tool: when a campaign's budget, schedule, status, or description needs changing. It does not, however, say when to prefer set_campaign_state for status-only changes or other sibling alternatives, so the guidance is implicit rather than explicit.

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 makes the mutation nature clear (delta update) and specifies that only the listed attributes are affected for existing variants, and that no full re-upload is needed. It does not, however, disclose merge/overwrite semantics, partial-failure behavior, idempotency, or authorization requirements, which are meaningful gaps for a mutation 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?

A single sentence front-loads the operation and scope and includes the key decision-relevant fact (no full catalog re-upload). There is no filler or repetition of schema field names beyond the meaningful summary.

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?

Combined with the rich input schema, the description is sufficient to understand what to send: a feed_id and product/variant objects containing only changed fields. There are minor gaps such as no mention of what happens for unknown variant IDs or partial failures, but they do not block correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents feed_id, products, and the price/title/availability fields in detail. The description adds the concept of 'delta' (only changed fields) but does not explain field formats like minor-unit pricing; that is handled by 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?

The description names a specific action (delta update), a clear resource (product feed variants), the updateable fields (prices, titles, stock availability), and the scope (existing variants in a linked merchant feed), distinguishing it from a full catalog re-upload. This is enough for an agent to 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 phrase 'existing variants ... without re-uploading the entire catalog' gives a clear usage context: partial updates to already-uploaded variant data. It implies that adding/removing variants or performing a full sync is out of scope, though it does not explicitly name a fallback tool or say 'do not use for new variants'.

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 and does add useful behavioral traits: the returned file_id is 'reusable' and serves two distinct purposes. It does not disclose persistence side effects (a stored asset on the ad account), authentication requirements, image format or size limits, or failure behavior for invalid URLs; the only constraint (min 128x128) lives in the schema.

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 24-word sentence with a clean action → outcome → use-cases arc and the verb front-loaded. Every word earns its place, with no filler or redundancy; the chat_card ambiguity is a content issue rather than a structure problem.

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 low-complexity tool (2 params, 1 required, no nesting, full schema coverage), the description is nearly complete: it names the input, the output (partially compensating for the absent output schema), and the two consumption contexts. It omits the default behavior when purpose is omitted and any upload constraints or failure modes, but these are minor given the 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 description coverage is 100%, with both parameters already documented (HTTPS requirement for image_url, enum and 128x128 note for purpose), so the baseline is 3. The description adds a use-case mapping for purpose (ads vs brand review), which is genuinely helpful, but the 'chat_card' reference corresponds to no enum value and slightly muddies that mapping.

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 names a specific verb ('Upload'), resource ('remote image URL'), target system ('OpenAI Ads'), and outcome ('reusable file_id'), and maps the result to two downstream uses. No sibling tool covers asset uploads, so it is easily distinguished from the crowd. Minor deduction because the description references 'chat_card' as a purpose while the schema enum only allows account_favicon and custom_audience.

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 call this tool — when a reusable file_id is needed for ads or an account favicon — by naming the two consumption paths. It does not state any when-not-to-use conditions or point to alternative tools, leaving routing decisions among the 40+ siblings to inference.

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