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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds genuinely non-structured behavior: the call verifies that the API key belongs to OPENAI_ADS_ACCOUNT_ID, making it a scope/auth preflight rather than just a getter. Error semantics (what a key/account mismatch returns) 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 short sentences: the first front-loads what is read and what comes back, the second front-loads the verification purpose and the call-ordering instruction. No filler and no repetition of structured fields beyond what aids scanning.

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

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

An output schema exists, so return values need not be spelled out, and annotations cover the safety profile. The description still supplies the two things an agent cannot infer from structure alone: this is the recommended first call, and it validates account/key scope. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and the single adAccountId parameter carries a pattern and a full explanation that other IDs are refused. The description reinforces the OPENAI_ADS_ACCOUNT_ID linkage but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Read the configured ChatGPT Ads account') and enumerates the returned fields (name, currency, time zone, status, brand review), so the agent knows exactly what this returns. It is implicitly distinct from the many sibling read tools, which all target sub-resources like campaigns, ad groups, and insights, but it never explicitly says so.

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?

'Run it first' is an explicit sequencing directive that tells the agent to make this the opening call. It also explains the tool doubles as an API-key/account-scope verification step. It stops short of naming alternatives or stating when not to use it, but for a singleton account-read tool there is little ambiguity.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that the response carries creative and review status, but 'no preview or change is requested' largely restates the readOnly hint rather than adding new behavioral context (e.g. account scoping, 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 short sentences, front-loaded with the core action and scope; nothing is wasted or buried.

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

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

An output schema exists, so return values need not be explained, and the description notes the key payload (creative + review status) for this simple single-record read. Minor gap: it doesn't mention the serving_issues option, though the schema covers 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 100%, so adId, adAccountId and the include/serving_issues option are fully documented in the schema. The description adds no parameter-level detail, which is acceptable at this coverage level, so the baseline 3 applies.

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

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

States a specific verb+resource: 'Read one ad with its creative and review status'. The singular 'one ad' implicitly distinguishes it from the list sibling openai_ads_get_ads, but no sibling is named explicitly.

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 preview or change is requested' implies a read-only lookup, and 'one ad' implies use when a single ad ID is at hand. However, there is no explicit guidance on when to choose this over openai_ads_get_ads or openai_ads_list_ad_creatives, and no exclusions are 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds a small amount of value by naming what the response contains (native bidding, context hints, product set), but it does not mention error behavior or the serving_issues opt-in that materially changes the payload.

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, which is the right shape for a simple read tool. It is slightly clipped, listing payload fields without explaining them, but 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?

An output schema exists and the schema fully documents all parameters, and annotations cover the safety profile, so the description need not carry return-format or mutation semantics. What remains missing is guidance on choosing this tool over the ad-groups list endpoint, but for a simple getter this is close to complete.

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

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

Schema description coverage is 100%, so all three parameters, including the include=serving_issues option and adAccountId scoping, are already documented in the schema. The description adds no parameter semantics of its own, so the baseline of 3 applies. The phrase 'context hints' is not clearly tied to any 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?

States a specific verb and resource: 'Read one ad group', and the singular phrasing implicitly distinguishes it from the sibling list tool openai_ads_get_ad_groups. The trailing clause names the payload contents (native bidding, context hints, product set), so the resource is unambiguous, but it never explicitly names the sibling it differs from.

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 when-to-use, when-not-to-use, or alternative is given. The word 'one' weakly implies a single-entity lookup versus the list endpoint, but the agent must infer that openai_ads_get_ad_groups is the alternative for enumeration. No prerequisites or exclusion conditions are 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral value by disclosing the paged result shape and the has_more/last_id contract, which an agent cannot infer from annotations. It omits rate limits or ordering guarantees, keeping it short of a 5.

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

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

Three short sentences, front-loaded with the core action, then the ID format, then the one operational caveat. No filler and nothing buried.

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

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

With an output schema present and full parameter documentation, the description need only cover purpose and pagination behavior, which it does. Minor gaps — such as whether results are scoped to the account's configured ID or how filters combine with paging — are handled by the schema, so the definition is nearly 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 every parameter (name, after, before, limit, order, include, campaignId, adAccountId) is already documented precisely. The description only restates the after/last_id relationship already present in the 'after' parameter description, adding little beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource+scope: "List one page of ad groups in a campaign." That clearly distinguishes it from the singular get_ad_group and from get_campaigns, though it never names those siblings explicitly. The added note about the adgrp_ ID prefix reinforces what kind of entity is returned.

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

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

Gives one concrete usage rule — "Follow last_id only when has_more is true" — which governs cursor reuse. However, it offers no guidance on when to pick this tool over get_ad_group or why you would page with limit/order, leaving selection context 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?

Annotations already declare this a read-only, idempotent, non-destructive, open-world operation, so the safety profile is carried. The description adds the has_more/last_id pagination coupling, but that same rule is already spelled out in the schema's 'after' parameter, and the return content is covered by the existing output schema — so incremental disclosure is modest.

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

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

Two tight sentences, purpose front-loaded and the pagination caveat immediately after. Nothing redundant or padded.

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

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

With annotations, a full-coverage schema and an output schema, the description only needs to nail purpose and pagination behavior — which it does. The remaining gap is routing guidance versus openai_ads_get_ad and the creative-listing sibling, which keeps it short of a 5.

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 every parameter (name filter, after/before cursors, limit, order, include, adGroupId, adAccountId) documented in the schema. The description adds no syntax, constraint, or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (List), resource (ads), scope (in an ad group) and what comes back (native creative metadata and review status). It does not explicitly distinguish itself from the singular sibling openai_ads_get_ad, but 'one page of ads' makes the list-vs-single contrast clear enough in practice.

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 only usage rule given is the pagination contract ('Follow last_id only when has_more is true'), which is genuine when-to-use guidance for cursoring. There is no statement of when to prefer this over openai_ads_get_ad or the creative/insight siblings, so alternative selection is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered without the description. The description adds little beyond that — 'native fields and pagination are preserved' is boilerplate-like for a single-resource read and never explains what lifecycle states exist or how an operation relates to the parent audience.

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

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

Three short sentences, front-loaded with the core action. The middle sentence about preserved native fields and pagination is of questionable value for a single-object read but costs little.

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

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

An output schema exists, so return-shape explanation is unnecessary, and annotations cover the safety profile. Still, the description never clarifies what an 'audience operation' is in this API (sync/bulk job?) or what the caller would do with the state, leaving the agent with a minimal picture.

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 all three parameters are documented in-schema, including the account-scoping constraint and the exact-ID requirement. The description adds no parameter-level meaning beyond that, so baseline 3 applies.

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

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

States a specific verb and resource: reads the lifecycle state of one custom audience operation. The singular 'one' implicitly separates it from the sibling list tool openai_ads_get_audience_operations, though that sibling is never 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?

Usage is only implied by the singular framing; there is no explicit when-to-use or when-not-to-use statement, and no comparison to openai_ads_get_audience_operations or openai_ads_get_custom_audience. The pointer to openai_ads_get_write_schema is a helpful adjacent reference but not a selection rule.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds that native fields and pagination are preserved, which is useful return-shape context, but says nothing about ordering, page size limits, or what 'accepted' means operationally.

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

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

Three short sentences, front-loaded with purpose. The trailing pointer to openai_ads_get_write_schema is questionable for a read-only listing tool and slightly muddies the intent, but costs little space.

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

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

An output schema and full annotation coverage reduce the burden, but the description leaves key ambiguity: what an 'accepted operation' is, and how this relates to the singular get_audience_operation sibling. Adequate but with clear 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 schema already documents adAccountId scoping and the limit/cursor query object. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

Specific verb+resource: lists the accepted operations of a custom audience. It is distinguishable from get_custom_audiences (list of audiences) and get_audience_operation (single operation), though it never explicitly contrasts 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?

Usage is only implied by the verb 'List'; there is no statement of when to call this versus openai_ads_get_audience_operation or openai_ads_get_custom_audience, and no prerequisite context such as requiring an existing audience.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds that native fields and pagination are preserved, which is useful pass-through context, but it omits what a log record contains and confirms nothing about rate limits or ordering defaults.

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, front-loaded with the operation and its filters. The trailing pointer to openai_ads_get_write_schema is a slight non-sequitur for a read-only audit tool but is short enough not to cost much.

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

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

An output schema exists so return values needn't be explained, and annotations cover the safety profile. Between the description and the richly described nested query object, an agent has what it needs; only the meaning/shape of an audit entry is left unstated.

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

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

Schema description coverage is 100% and the adAccountId constraint (API-key-scoped, refusing other IDs) is already documented in the schema. The description's "entity, actor or time" mapping roughly matches campaign_id/ad_group_id/ad_id, actor_id and start_time/end_time, but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

"List recorded changes to the account's campaigns, ad groups and ads" is a specific verb+resource and identifies the audit-log surface, which no sibling covers. It does not, however, explicitly contrast itself with the get_campaigns/get_ads siblings an agent might otherwise pick when looking for history.

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 "optionally filtered by entity, actor or time" implies the retrieval scenarios (change history, per-actor investigation) but never states when to use this instead of a direct entity read. No exclusions or prerequisites are given, leaving usage to 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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real context beyond them: the limited-preview/per-account gating, which statuses are terminal, and the caveat that a completed job still needs per-operation and native-entity reads - a non-obvious behavioral trap an agent would otherwise miss.

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

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

Three terse sentences, front-loaded with the action and gating, followed by the two pieces of lifecycle information that matter. No filler or restatement of the title.

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

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

With an output schema present, return values need no explanation, and the description covers availability gating and terminal-state semantics. Only the relationship to the operations sibling tool is left unstated.

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

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

Schema description coverage is 100%, with both jobId and adAccountId fully documented including pattern and account-scoping semantics. The description adds nothing about parameters, so baseline 3 applies.

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

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

States a specific verb and resource ('Read one Bulk API job') and adds scope qualifiers ('limited preview, enabled per account') that an agent cannot infer from the name. It is distinguishable from the sibling openai_ads_get_bulk_job_operations, though it never names that sibling explicitly.

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 terminal-state note ('only completed, partially_failed and failed are terminal') implies polling usage, and the final sentence hints that results live elsewhere. However, it never explicitly says when to call this versus openai_ads_get_bulk_job_operations or how polling should proceed, so 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?

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile needs no restating. The description adds genuinely non-obvious behavior: partial failures never roll back earlier operations, and callers should not resubmit an uncertain job. It does not mention ordering of results or rate/volume limits, leaving a little on the table.

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

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

Three short sentences, zero boilerplate, and the resource scope is front-loaded before the paging rule and the failure caveat. Every sentence carries actionable information.

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

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

With an output schema present, the description needn't explain return values, and the account-scoping and jobId format are covered by schema descriptions. What remains is solid for a paginated read tool, though a note on result ordering or whether operations can appear on later pages would complete the pagination story.

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 conditional rule the schema does not encode: 'after' should only be supplied when has_more is true, which clarifies the cursor's correct use. The 'limit' parameter's range and defaults are left entirely to the schema.

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

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

States a specific verb (read) and resource (one page of Bulk API operation outcomes) and even enumerates the outcome categories: created, updated, validated, failed, skipped. An agent can immediately tell this is the per-operation log rather than job status, but the description never names the obvious sibling openai_ads_get_bulk_job to make the distinction 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?

Gives a concrete usage rule for the pagination cursor: pass the last operation_id as 'after' only when has_more is true, plus a caution not to resubmit an uncertain job. It stops short of stating when to call this versus get_bulk_job or the mutation-lookup siblings, so the alternative-selection guidance is implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds that the response includes native status, budget, schedule and targeting, which is useful context, but with an output schema present that field list is partly redundant and no auth or rate-limit behavior is disclosed.

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?

It is a single, front-loaded sentence with no filler. Every element (read, one campaign, returned fields) 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 simple single-object read tool with full schema coverage, an output schema, and rich annotations, the description is essentially complete. The only missing element is explicit routing guidance versus sibling read/list tools.

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

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

Schema description coverage is 100%, and each parameter (adAccountId, campaignId, include) has clear structured documentation, so the baseline of 3 applies. The description itself adds no syntax or semantic detail about the parameters beyond implying a single campaignId lookup.

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

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

The description states a specific verb ('Read') and resource ('one campaign') and lists the data returned (status, budget, schedule, targeting). The word 'one' implicitly distinguishes it from the plural list sibling openai_ads_get_campaigns, though no sibling is named explicitly.

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

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

Usage is implied by 'Read one campaign' with a campaignId required, but there is no explicit when-to-use guidance or comparison to alternatives like openai_ads_get_campaigns or the insights tools. An agent can infer the single-campaign fetch case but receives no exclusions or routing advice.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description earns credit for what it adds: this is a single-page operation requiring cursor chaining, and budget values are in account-currency micros. It does not mention rate limits or ordering defaults beyond what the schema states.

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

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

Three short sentences, zero filler, with the core action front-loaded and the pagination caveat immediately after. Nothing redundant with the schema.

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

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

An output schema exists, so return values need no explanation, and the pagination contract plus micros convention are the key non-obvious behaviors for a list endpoint. Minor gap: no hint about how name filtering or ordering interacts with paging.

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 all seven parameters are already documented, including the 'after'/'before' cursors and the serving_issues include flag. The description reinforces the last_id/has_more linkage but adds no syntax or constraints the schema lacks; baseline 3 applies.

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

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

States a specific verb and resource with scope: 'List one page of campaigns in the account.' The singular/plural distinction against the sibling openai_ads_get_campaign is implicit in 'campaigns' and 'one page', but no sibling is named explicitly.

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 cursor rule ('Follow last_id only when has_more is true') is a usage instruction, but it governs pagination mechanics rather than when to choose this tool over openai_ads_get_campaign or the insights tools. Selection guidance is left to inference from the 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?

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds valuable context beyond that: events are sampled and recent, native fields and pagination are preserved, and nested request fields are documented in openai_ads_get_write_schema. It doesn't detail rate limits or return format, but the output schema covers the latter.

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

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

Three short sentences, front-loaded with purpose and followed by behavioral details and a pointer to a related tool. No wasted words.

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

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

With an output schema present and annotations covering the safety profile, the description fills remaining gaps by mentioning sampling, pagination preservation, and where to find nested field documentation. It is complete enough for an agent to call it correctly, though it doesn't mention the query limit cap (which the schema provides).

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

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

Schema description coverage is 100%, so the schema itself documents both parameters well. The description adds guidance by pointing to openai_ads_get_write_schema for nested request fields, which is useful for an agent dealing with the nested 'query' object.

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

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

States a specific verb ('List') and resource ('conversion events'), plus a scoped qualifier ('recent sampled') and a concrete use case ('checking that a pixel or server integration sends data'). This distinguishes it from analytics-oriented siblings like openai_ads_get_conversion_insights, though no sibling is 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?

The description gives a clear when-to-use context: verifying that a pixel or server integration is sending data. It does not state when not to use it or explicitly name alternatives, but the context is sufficient for an agent to route 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that native fields and pagination are preserved, but it does not disclose auth constraints, rate limits, or other behavioral details beyond what annotations and schema already provide.

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 three tight sentences, front-loaded with the core purpose, followed by behavioral context and a relevant schema pointer. Every sentence contributes useful information without 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?

Given the output schema, rich input schema, and strong annotations, the description is nearly complete for invocation. The main remaining gap is the lack of explicit sibling differentiation from openai_ads_get_insights and conversion-event tools.

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

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

With 100% schema description coverage, the baseline is 3, but the description adds useful meaning by mapping country/device to breakdown, daily values to granularity, and event details to include. It also correctly routes nested request fields to openai_ads_get_write_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 states a specific read operation for attributed conversion insights, including totals or daily values and optional country/device breakdowns. It is clearly distinct from generic account/campaign tools, though it does not explicitly differentiate itself from the sibling openai_ads_get_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?

It implies when to use the tool for conversion attribution reporting and lists optional dimensions, but it gives no explicit when-to-use versus alternatives such as openai_ads_get_insights or openai_ads_get_conversion_events. The pointer to openai_ads_get_write_schema helps with nested fields but is 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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered structurally. "Native fields and pagination are preserved" adds a little behavioural context about response shape, but "preserved" is vague about whether pagination tokens are returned or handled internally. No mention of rate limits or page-size behaviour beyond what the schema states.

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

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

Three short sentences, purpose front-loaded, no filler. The final sentence about write_schema is the weakest link concision-wise because it points a read tool at a write-schema helper.

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?

Annotations and an output schema exist, and required/optional parameters are fully documented, so most of the burden is already met. The description leaves scope ambiguity versus the other conversion_* tools and includes a possibly misleading write-schema pointer, which keeps it from being 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%, including a documented adAccountId constraint and a fully described nested query object, so the schema carries parameter meaning. The description adds nothing about parameters, which is acceptable at this coverage level but is only 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?

"List the account's conversion pixels and connected pixel IDs" gives a specific verb (list) and resource (conversion pixels), and the output content is named. It does not explicitly distinguish itself from near-neighbour siblings such as openai_ads_get_conversion_settings or openai_ads_get_conversion_events, though the resource noun differs enough to be workable.

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 statement of when to pick this over the conversion_settings/conversion_events siblings, so usage is only implied by the resource name. The one routing pointer present ("See openai_ads_get_write_schema") is a cross-reference but not a when/when-not rule, and it is arguably misdirected for a read-only list 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds a useful pagination note ('Native fields and pagination are preserved'), but that is the only behavioral detail beyond structured data.

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

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

Three short sentences, front-loaded with the core action. The trailing write-schema reference is arguably wasted space on a read tool, but nothing else is padded.

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

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

A read-only listing tool with an output schema, full schema coverage and complete annotations does not need much more. The description covers purpose and pagination behavior; only sibling disambiguation is missing.

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

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

Schema description coverage is 100%, including the adAccountId scoping rule and the native query object, so the baseline is 3. The description's pagination remark loosely maps to after/before/limit/order but adds no syntax or constraint detail beyond the schema.

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

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

States a specific verb and resource: 'List the account's conversion event settings, the goals a campaign can use.' The resource is identified precisely enough to invoke, but it does not differentiate from closely named siblings such as openai_ads_get_conversion_events or openai_ads_get_conversion_pixels.

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

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

Usage is implied by the resource name rather than stated. The only explicit routing is 'See openai_ads_get_write_schema for nested request fields,' which is a curious pointer for a read-only list tool and gives no guidance on when to prefer conversion settings over conversion events or pixels.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description usefully adds that a matched count is returned and that native fields/pagination are preserved, but says nothing about auth scoping (the schema carries that) or rate/paging limits.

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

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

Three short sentences, front-loaded with the core action and return payload. Little waste, though the trailing write-schema reference is the weakest sentence and arguably doesn't earn 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?

An output schema exists, so return shape needn't be explained, and the rich parameter descriptions cover the inputs. What's left thin is the routing guidance versus openai_ads_get_custom_audiences and the unexplained relevance of the write-schema pointer for a 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 description coverage is 100%, including the matched_count_granularity constraint and the adacct_ pattern, so the schema already does the work and baseline 3 applies. The description adds no parameter-level detail beyond a vague redirect to the write schema, which does not apply to request fields here.

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

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

States a specific verb and resource — 'Read one custom audience and its matched count' — and the singular scope implicitly distinguishes it from the sibling list tool openai_ads_get_custom_audiences. It does not name that sibling explicitly, so the differentiation is inferred rather than stated.

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?

Conveys that this retrieves a single entity, which implies the when-to-use case versus the plural list tool, but never states it. The pointer to openai_ads_get_write_schema is puzzling for a read-only tool and doesn't help an agent decide between alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. 'Native fields and pagination are preserved' adds a little context about response shaping and paging, but the cross-reference to openai_ads_get_write_schema muddies rather than clarifies behavior for a pure read 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?

Three short sentences with the core action front-loaded and no filler. The third sentence doesn't earn its place as well as the first two, since it redirects to a write schema.

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

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

With an output schema present and 100% schema coverage, the description needs only to name the operation and note paging, which it does. The only soft spot is the unexplained pointer to the write schema, but an agent can still call this correctly.

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

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

Schema description coverage is 100%, so both parameters (adAccountId and the nested query object) are already documented in the schema, including the adacct_ scoping constraint. The description adds nothing about the pagination cursor or filter fields beyond a vague 'native fields' remark, so baseline 3 applies.

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

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

States a specific verb and resource: 'List the account's custom audiences.' The plural 'audiences' plus the name makes it distinguishable from the sibling openai_ads_get_custom_audience, though the description never explicitly contrasts the two.

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

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

Usage is only implied by the verb 'List' – nothing says when to choose this over openai_ads_get_custom_audience (single) or openai_ads_get_audience_operations. The one routing hint, 'See openai_ads_get_write_schema for nested request fields,' points to a write schema from a read-only listing tool, which is ambiguous rather than helpful.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only "Native fields and pagination are preserved," which is close to a non-statement — it does not say what the pagination contract is (cursor via `after`, max 500) or what the filter semantics do.

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

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

Three short sentences, lead sentence carries the core purpose, no throat-clearing or repetition of the title. The middle sentence about "native fields and pagination" is the weakest line and borders on filler, keeping it off a 5.

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

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

An output schema exists, so return formatting need not be explained, and the body/filter schema is fully documented. Still missing for a nested-body tool: nothing tells the agent that filters apply to feed product fields, that page size is capped at 500, or how this differs from the other feed-listing tools.

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

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

Schema description coverage is 100%, so the schema already documents adAccountId scoping and the exact-body semantics; baseline 3 applies. The description contributes the redirect to openai_ads_get_write_schema for nested request fields, which is minor added value rather than new parameter meaning.

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

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

States a specific verb and resource ("List products in a feed") plus a scoping qualifier ("that match ad group product filters"). It is distinguishable from the nearby feed siblings (get_feeds, get_feed_uploads, get_feed_settings) by naming the product collection, though it never explicitly contrasts itself with them.

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

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

Usage is only implied by the purpose sentence — an agent can infer "use this to look up feed products for an ad group." There is no when-to-use/when-not-to guidance versus get_feeds or get_feed_settings, and the one routing pointer ("See openai_ads_get_write_schema") addresses schema lookup, not tool selection.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive operation. The description adds useful behavioral context that native fields and pagination are preserved, going beyond the structured safety hints.

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

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

Front-loads the core action and stays short. The reference to openai_ads_get_write_schema is a bit tangential for a read/list tool but does not bloat the description.

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

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

Given the output schema exists and annotations cover safety, the description is largely sufficient. It could explicitly differentiate sibling feed-related tools, but nothing critical is missing for invocation.

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

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

Schema coverage is 100%, so the parameters are already documented. The description adds only the product_count option, while pagination behavior is mostly left to the schema.

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

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

States a specific verb and resource: list the account's product feeds. It distinguishes the resource from feed_products and feed_settings implicitly, though it does not explicitly route to 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?

The optional product-count behavior is clear, but there is no explicit guidance on when to use this tool versus openai_ads_get_feed_products, openai_ads_get_feed_uploads, or openai_ads_get_feed_settings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that native fields and pagination are preserved in the response, which is modest but genuine context about output shape. It does not mention any auth/account scoping or failure behavior, though the schema does.

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 purpose sentence is front-loaded and efficient. However, the trailing sentence directing the agent to openai_ads_get_write_schema for request fields does not earn its place in a read-only tool with no request body, and reads as boilerplate noise.

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

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

An output schema exists and annotations are rich, so return values and safety need not be spelled out. What is still missing is any indication of how the returned settings relate to the sibling feed endpoints, leaving the agent to infer placement from the name alone.

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

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

Schema description coverage is 100% and both parameters are documented in detail, including the adacct_ pattern and account-scoping rule. The description contributes no additional parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb and resource: read a feed's display and organic-listing settings. The resource scope is narrow enough to distinguish it implicitly from siblings like openai_ads_get_feed_products and openai_ads_get_feed_uploads, but no sibling is named outright.

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

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

There is no statement of when to call this versus openai_ads_get_feeds or any other feed-related sibling. The only routing sentence points at openai_ads_get_write_schema for 'nested request fields', which is confusing for a read-only tool and gives no 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that native fields and pagination are preserved and that processing results are included, but says nothing further about page size, defaults, or ordering; the write_schema pointer adds no behavioral clarity for a read.

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?

Only three short sentences and the purpose is front-loaded, which is good. However, the trailing write_schema sentence does not earn its place on a read-only listing tool and risks sending the agent down an irrelevant path.

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

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

An output schema exists, so return-value explanation is unnecessary, and annotations carry the safety profile; the nested query object is fully documented in the schema. The remaining gap is the misplaced write_schema cross-reference and the absence of any note on how upload statuses relate to get_feeds.

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 after/before/limit/paginate and the adacct_ scoping are already documented in structured fields. 'Pagination is preserved' lightly reinforces the query object but adds no syntax or limits beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('List recent product feed uploads and their processing results'), which cleanly separates it from siblings like get_feeds, get_feed_products, and get_feed_settings. An agent can identify what this returns 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?

No guidance on when to pick this over get_feeds or get_feed_products, nor any prerequisites or exclusions. The only pointer given ('See openai_ads_get_write_schema for nested request fields') is a write-path reference on a read-only listing tool, so it does not help selection.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds real value: default attribution windows, fraction vs major-unit semantics for CTR/CVR and money, and the paging/truncation contract up to maxRows. The only gap is it does not say anything about concurrency or refresh latency, so it stops just short of the top.

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

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

Five compact sentences, front-loaded with purpose before constraints and result semantics; every clause (breakdown limits, attribution defaults, units, paging) carries distinct information with no repetition of the schema.

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

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

With 9 params, nested attribution object, and an output schema, the description covers exactly what structured fields cannot: alternative-routing, unit conventions, and truncation behavior. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so parameter syntax is already documented; the description nonetheless adds semantics the schema lacks – attribution defaults (30-day click, 1-day view, ad_event_time), the single-breakdown-per-request restriction, and 'use conversion_insights for conversions by country or device.' That is meaningful incremental guidance over baseline 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?

Opens with a specific verb+resource and scope: 'Read performance by account, campaign, ad group or ad over inclusive account-local dates.' A reader immediately knows it is the delivery/performance report at any entity level, distinguishing it from the entity-listing siblings and from openai_ads_get_conversion_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?

Explicitly routes conversions-by-country/device to openai_ads_get_conversion_insights, and states the breakdown constraint ('delivery metrics only', 'one optional ... breakdown'). Both the when and the when-not are named.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description does add that the evidence is 'saved' (a stored snapshot rather than a live crawl) and that native fields and pagination are preserved, but it is silent on freshness, whether a crawl may be absent, and auth scoping beyond 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?

Three short sentences with the purpose front-loaded and zero filler. The trailing pointer to openai_ads_get_write_schema for 'nested request fields' is questionable for a flat two-parameter read tool and slightly dilutes an otherwise tight 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?

With an output schema present, rich annotations, and 100% parameter coverage, the description only needs to frame the resource, which it does. The minor gap is that 'an ad's submitted version' implies a version dimension that the two-parameter schema never exposes, leaving how a specific version is addressed unexplained.

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 both parameters carry detailed descriptions including the adacct_ pattern and account-scoping constraint, so the schema does the heavy lifting. The description only implies the ad/account pairing via 'an ad's submitted version' and adds no syntax or identity-format detail of its own.

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

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

States a specific verb ('Read') and a distinct resource ('saved landing page crawl evidence for an ad's submitted version'), which clearly separates it from generic ad reads like openai_ads_get_ad. It stops short of explicitly naming a sibling it should be preferred over, so it lands at a clear-but-not-differentiating 4.

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

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

There is no when-to-use/when-not guidance and no mention of prerequisites such as needing a prior crawl or submission. The only routing hint points at openai_ads_get_write_schema for 'nested request fields', which reads like boilerplate for a two-parameter read tool and does not help an agent choose between this and openai_ads_get_ad or openai_ads_list_ad_creatives.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's real contribution is lifecycle behavior: receipts are held in memory and a restart forgets them, and certain states must never be followed by a resubmit. That transient-state warning is exactly the kind of non-obvious trait annotations cannot express. It stops short of describing receipt contents in detail or what to do on each 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?

Three short sentences: what it reads, what the data's lifetime is, and the safety prohibition. The most operationally important fact (in-memory, lost on restart) and the unsafe-state warning are both front-loaded with no filler.

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

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

With a full output schema and complete annotations, the only things the description needs to add are lifecycle and hazard context, which it does. The remaining gap is workflow positioning — it never says what to call first to get a confirmationToken, so the entry point into this tool is left implicit.

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

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

Schema description coverage is 100%, and both parameters carry their own documentation, including the accepted confirmationToken-or-mutationId form and the adacct_ account scoping. The description adds nothing beyond that. Baseline 3 is correct when the schema carries the full parameter burden.

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 object: read a write preview or receipt, and enumerates what it returns (state, the native state it was approved against, the result). That is far more precise than the sibling get_* tools, which fetch ad entities. It does not explicitly differentiate itself from close siblings like openai_ads_get_write_context or openai_ads_get_bulk_job, which an agent could plausibly confuse it with.

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 mostly implied: the emphasis on the approval state suggests polling after a write preview, and 'Never resubmit a write whose state is UNKNOWN or APPLYING' is a hard exclusion rule. But there is no explicit statement of when to call this versus get_write_context or get_write_schema, nor what to do with each returned state. The agent must infer the workflow.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds one genuinely useful behavioral note — that native fields and pagination are preserved — but says nothing about result volume, freshness, or whether windows are computed server-side.

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

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

Three short sentences with the purpose front-loaded and the pagination note second. The trailing pointer to openai_ads_get_write_schema is questionable for a read-only tool and is the one part that does not clearly earn 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?

An output schema exists, annotations cover the safety and idempotency profile, and the single parameter is fully specified in the schema, so the description does not need to explain return values. What remains slightly thin is usage context — when this view is preferred over get_account — and the write-schema reference adds mild confusion rather than clarity.

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

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

Only one parameter exists and its schema description is fully documented at 100% coverage, including the adacct_ pattern and the single-account API key scoping. The description adds no additional meaning about adAccountId, so the baseline of 3 applies.

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

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

States a specific verb (Read) and a specific resource (account's spend limit windows and daily recurrence rules), which is narrow enough to distinguish it from campaign/insight/feed siblings. It stops short of naming a contrasting sibling or clarifying when the spend-limit view differs from get_account, so it lands at 4 rather than 5.

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

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

There is no statement of when to call this versus get_account or the other account-level reads, nor any prerequisite or exclusion. The only guidance is a pointer to openai_ads_get_write_schema, which is about write payloads and does not tell the agent when to use this read tool.

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

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

Annotations already cover read-only, idempotent and non-destructive, so the safety profile is known. The description adds real value beyond them: it clarifies that despite the 'write context' name it creates nothing and grants no eligibility, and it discloses that missing prerequisites are surfaced in the response — a meaningful behavioral caveat.

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

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

Three short sentences, each earning its place: what to read, what comes back, and the key non-effect caveat. The purpose is front-loaded before the caveat, with no filler.

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

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

An output schema exists, so return structure need not be explained; annotations cover safety; the sole parameter is fully documented in the schema. The description supplies exactly the missing pieces — timing (pre-campaign), content hint, and the 'creates nothing' caveat.

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 adAccountId parameter already documents the adacct_ pattern and the single-account API key scoping. The description adds nothing about the parameter, so the schema does all the work — baseline 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 concrete verb and a composite resource set: reading the account, its conversion settings and product feeds. The phrase 'before proposing a campaign' signals this is a bundled pre-write context read rather than the single-resource getters (get_account, get_conversion_settings, get_feeds) it overlaps with, but it never names those siblings explicitly.

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

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

'Read ... before proposing a campaign' gives a clear triggering condition for use, and 'It grants no eligibility' implicitly rules out the misreading that it is an eligibility check. It does not name alternatives (e.g. get_write_schema for the mutation schema), so the when-not/alternative half is not 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?

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable behavioral context: it returns pinned definitions, upload/bulk limits, server omissions, and warns that schema support does not equal account eligibility. It does not mention response format, but an output schema exists.

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 tightly written sentences with no wasted words. The core purpose is front-loaded, and the caveat is appropriately placed at the end as a qualifier.

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

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

With an output schema present and annotations covering safety, the description provides enough additional context (limits, omissions, eligibility caveat) for an agent to understand what the tool returns and how to interpret it. No critical gaps for this introspection 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 both parameters are fully documented in the schema itself. The description adds no additional meaning beyond what the schema provides, which is acceptable for a high-coverage 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 a specific verb ('Read') and the exact resource ('pinned native request definitions, paths and parameters of every operation, upload and bulk limits, and what this server leaves out'). It distinguishes this introspection tool from sibling data-retrieval tools implicitly, but does not explicitly contrast with similar write-related tools like get_write_context or get_mutation.

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 purpose implies when to use it (to discover operation schemas), but there is no explicit guidance on when to choose this over alternatives or prerequisites for use. The caveat 'Schema support does not imply that the account is eligible for a feature' is helpful context but not usage routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds meaningfully beyond them: page size of 20, the nextCursor/hasMore pagination contract, the exact fields each item carries, and the non-obvious side effect that an expired image link is refreshed with one ad read. It omits rate limits and error behavior, so 4 rather than 5.

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

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

Three dense sentences with zero filler: capability and modes first, then item shape, then the pagination/refresh caveats. Every clause carries operational information an agent needs.

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

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

With an output schema present, return values need not be fully explained, yet the description still summarizes item fields; annotations cover safety, and the description covers pagination and the image-refresh quirk. Nothing needed to call this correctly is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented, and the description largely restates the schema ('20 ads per page' mirrors limit max 20, 'up to 60 exact adIds' mirrors maxItems 60). It does clarify that the modes are alternatives, but adds little semantic detail the schema lacks, so the baseline 3 is right.

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

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

States a specific verb (List) and a precisely scoped resource (chat card creatives), plus the three addressing modes: whole account, one ad group, or exact adIds. It does not name a sibling (e.g., openai_ads_get_ads / openai_ads_get_ad) to clarify how 'creatives' differs from 'ads', so it stops short of 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 description makes the three usage contexts explicit ('of the account or of one ad group... or read up to 60 exact adIds') and instructs the agent to follow nextCursor when hasMore, which is a genuine when-to-do-what rule. It offers no exclusions or named alternatives versus sibling read tools, so not 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?

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description still earns credit for adding that native fields and pagination are preserved, which clarifies the paging behavior the schema only hints at ("Each call reads one page unless the tool says otherwise"). It does not mention rate limits or result caps, so not a 5.

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

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

Three short sentences, front-loaded with the purpose, then the passthrough/pagination trait, then the cross-reference. Nothing is redundant and every sentence carries information.

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

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

An output schema exists so return values need not be explained, and annotations carry the safety profile. Purpose, paging behavior and a pointer to nested-field documentation are all covered; only explicit guidance on when this search is required is missing.

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

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

Schema coverage is 100%, so q (minLength 1), limit (1-100) and the adacct_ pattern are already fully documented in structured fields. The description adds no syntax or format guidance for the search term beyond what the schema provides, so the baseline 3 applies.

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

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

The description uses a specific verb (search) on a specific resource (country, region and market location IDs) and names the downstream purpose (campaign geographic targeting). No sibling tool overlaps this lookup, so differentiation is implicit rather than stated, which keeps it just short of a 5.

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

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

"For campaign geographic targeting" implies the use case but never says when to call this versus the many get_* siblings, nor whether it must precede campaign creation. The pointer to openai_ads_get_write_schema is a useful cross-reference but addresses a different concern than invocation timing.

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