Opus Growth, Ad Platforms MCP Connector

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered by structured data. The description adds no behavioral context beyond that — no scope of what the audit scans, no mention that results are advisory — so it neither extends nor contradicts the annotations.

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

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

Two sentences, no filler, with the purpose front-loaded and the date semantics following. The 'DATE:' prefix is a slightly dense shorthand but keeps it compact.

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

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

An output schema exists so return values need not be described. However, for a 3-parameter audit tool with 0% schema coverage, the description omits the required customer_id and any guidance on choosing this audit over sibling audits, leaving meaningful gaps.

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

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

Schema description coverage is 0%, so the description must carry the load. It usefully explains that 'period' overrides 'days', that days=0 means today, and gives example date formats, but 'customer_id' (the sole required parameter) is never mentioned and 'period' enum values are only hinted with '…'.

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+resource ('Account hygiene audit') and names what it surfaces ('wasteful keywords and low Quality Score'), so an agent knows it is a diagnostic read. It does not distinguish itself from close siblings like instant_audit or keyword_quality_report, leaving the agent to guess which audit to pick.

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

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

There is no when-to-use guidance, no prerequisites, and no routing to alternatives, despite several audit-shaped siblings (instant_audit, seo_audit, keyword_quality_report). The only context is implicit in the phrase 'account hygiene audit'.

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 declare non-read-only, non-idempotent, non-destructive, but the description adds real behavioral context the annotations lack: bulk application of a default match_type to items without their own suffix, and confirm=false producing a dry-run. It does not discuss auth requirements or rate limits, but the dry-run and mixed-set-in-one-call behavior are valuable disclosures.

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-loaded with the core purpose, then usage routing, then parameter syntax. Dense and information-rich, though the all-caps emphasis and repeated restatement of the suffix syntax add slight length without new 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 no explanation, and annotations cover the safety profile. The description covers purpose, alternatives, dry-run, and match-type semantics; only edge cases like duplicate-keyword handling or error behavior are unaddressed.

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 0% schema description coverage, the description must carry the load and largely does: it defines match_type values (PHRASE | EXACT | BROAD), the per-keyword '|EXACT' suffix override syntax with a concrete example, and confirm=false as dry-run. customer_id and ad_group_id are left implicit, which is a minor gap.

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

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

States a specific verb and resource (ADD POSITIVE KEYWORDS to a Google Ads ad group), including bulk scope, and explicitly distinguishes itself from the negative-keyword tool. An agent can route correctly without opening either schema.

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

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

Gives explicit when-not guidance (add_negative_keyword is only for BLOCKING traffic), names manage_keywords for pause/enable/re-bid of existing keywords, and describes the move workflow (add on target, remove from old). Clear alternatives and triggers throughout.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds substantially beyond them: confirm=false triggers a dry-run, location assets are created automatically once the Business Profile is linked, pinning is idempotent-ish account-wide vs campaign/ad-group scoping, and there is an external auth dependency on Business Profile API approval. That is real behavioral context not derivable from structured fields.

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 numbers the three decision branches, so it reads well despite its length. It is denser than most definitions need and some parenthetical detail (e.g. the full set of asset types in the first sentence) could be trimmed, but nothing is filler.

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

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

For a moderately complex, non-idempotent mutation tool with an output schema present, the description covers prerequisites, the dry-run path, the scoping options, and the fallback when no link exists. Return values are covered by the output schema, so nothing an agent needs to invoke 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 0%, so the description must carry the burden, and it does: confirm (dry-run toggle), campaign_id (pin asset set to campaign), ad_group_id (pin to a single ad group via AdGroupAssetSet, with a concrete branch example), and asset_set_id (select a specific location group like "Bağcılar", sourced from the tool's own location_asset_sets output). Only customer_id is left implicit, which is standard boilerplate.

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 precise verb and resource (attaches Google Business Profile LOCATION assets) and immediately scopes what the tool actually does: detect an existing linked location asset set, optionally pin it, or return link instructions. It is clearly distinguishable from siblings like connect_business_profile, manage_extension_assets, and add_microsoft_location_target.

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 describes the three branching conditions (asset set exists + campaign_id given → pin; exists without campaign_id → nothing to do; none exists → return linking steps) and names the ad-group-level alternative via ad_group_id. It also flags the upstream prerequisite (Business Profile API access pending approval) so the agent knows when this tool cannot complete the job.

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 flag this as a non-read-only, non-idempotent, open-world mutation, so the description's main added value is the two-phase confirm=false preview / confirm=true apply behavior and the fact that it writes to the account library and then attaches in one call. It does not mention rate limits or auth scopes, so it lands above baseline but not maximal.

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?

Purpose first, then compact format specs for sitelinks and callouts, then the confirm semantics in one trailing clause. No filler sentences; every clause carries information an agent needs to format the call correctly.

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 6-param mutation with an output schema present, the definition covers the semantics of the two content params, the confirm flag, and the attach behavior. The missing bits are the untouched identifier params (campaign_id/account_id/customer_id) and any note on error/partial-attach behavior, which are real but modest 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 0%, so the description must carry the meaning of every parameter, and it does document sitelinks format ('Display text|https://url' or 4-pipe variant, <=25 chars), callouts ('Free shipping'), and confirm (preview vs apply). It leaves account_id, campaign_id, and especially customer_id (which is optional and undocumented) without explanation, so it is not fully compensating.

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 (adds) plus resource (SITELINK/CALLOUT ad extensions) on a Microsoft (Bing) campaign, with a plain-language gloss of what a sitelink and a callout are. Clearly distinguishable from siblings like list_microsoft_ad_extensions and remove_microsoft_ad_extensions.

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?

Defines what each extension type is and gives format examples, and distinguishes this add-tool from the remove/list siblings by implication. It does not explicitly state when NOT to use it or explain the preview-vs-apply tradeoff beyond the confirm flag, so it falls just short of a full routing 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 declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: confirm=false previews (a dry-run mode) and that hours are interpreted in the account's time zone. It does not state whether the call replaces an existing schedule or errors if one 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?

The purpose and rationale are front-loaded, then parameters are documented compactly with no filler. Every sentence adds 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 described. For a mutation tool with a 7-parameter schema and annotations covering safety, the description supplies the missing parameter syntax, semantics, dry-run behavior, and motivation — nothing critical is absent.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely meets it: it defines days syntax including the 'weekdays'/'weekend'/'all' shorthands, from_hour/to_hour range and time-zone basis, and the bid_adjustment percentage convention with an example. account_id and campaign_id are left undocumented but are self-evident identifiers.

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 ('Sets WHEN a Microsoft (Bing) campaign is allowed to serve') and scopes it to Microsoft, which implicitly separates it from the sibling set_ad_schedule (Google) and get_ad_schedule (read). An agent can identify the operation immediately.

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?

Explains the operational context clearly ('Without an ad schedule the campaign runs 24/7 and burns budget at night'), which tells the agent when this is warranted. It stops short of explicitly naming the alternative tools or prerequisites, so it is clear context without full routing guidance.

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

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

Annotations declare a non-read-only, non-idempotent, non-destructive write but say nothing about workflow. The description adds genuinely new behavior: confirm=false previews, confirm=true applies, which is critical for a mutation tool. It stops short of permissions/rate-limit/error context.

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?

Four compact clauses, operation first, each parameter annotation in-line; zero filler sentences. The confirm semantics land last, which is the right place for a workflow note.

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?

Output schema exists so return values need not be explained, and the preview/apply contract covers the main safety concern. Gaps are the identity parameters (account_id/campaign_id/customer_id usage) and whether the adjustment is applied at campaign or ad-group level.

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

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

Schema description coverage is 0%, so the description carries the burden and does partially compensate: it supplies the criterion_type domain (Age | Gender), a value format example (TwentyFiveToThirtyFour, Male | Female) and the unit for bid_multiplier (%). It says nothing about account_id, campaign_id or customer_id, leaving 4 of 7 parameters undocumented anywhere.

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: 'Adds a demographic bid adjustment' with the exact Microsoft surfaces it touches (Age | Gender criterion, bid multiplier). An agent can tell it apart from add_microsoft_device_target or add_microsoft_location_target by subject matter, but the description never explicitly names or contrasts a sibling.

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

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

Usage is implied by the criterion/value enumeration rather than stated: no 'use this when' or 'prefer X instead' and no prerequisite (e.g. campaign must exist, account must be connected via connect_microsoft_ads). The confirm=false/true preview workflow is the only workflow guidance offered.

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 mark this as a non-destructive, non-idempotent write (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds meaningful behavior beyond that: the mandatory three-value constraint, that values are percent bid adjustments with 0 meaning no change, and the preview/apply semantics of confirm.

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 that lead with the action and the mandatory constraint, then the value semantics and confirm modes. No filler, though the parenthetical formatting is slightly compressed.

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 covering return values, the description only needs to cover invocation concerns. It handles the mutation behavior, the required-together constraint, and preview vs apply, leaving only identifier parameters unaddressed, which is a minor gap for a 7-param tool.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It does well for the device values (percent adjustments, 0=no change, send all three together) and for confirm, but account_id, campaign_id, and customer_id are never explained even though two are required. Partial compensation warrants a 3.

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

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

States a specific verb (adds) and resource (device bid adjustments for Microsoft), which is enough to distinguish it from siblings like add_microsoft_demographic_target or manage_device_targeting. It does not explicitly name an alternative sibling, so it stops short of a 5.

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

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

Gives concrete usage context: all three device values must be sent together (a Microsoft requirement) and confirm=false previews while confirm=true applies. It does not compare against the closest sibling manage_device_targeting, so it provides clear context but no explicit 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 declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds the important non-obvious behavior that this is a staged two-phase write (preview vs apply), which the annotations do not encode. It does not mention idempotency (annotations say false, so re-adding duplicates may occur) or per-call keyword 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 tight fragments with zero filler; the core action comes first, followed by the match_type values and the confirm semantics. Every sentence carries 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?

An output schema exists, so return values need not be explained. But for a 6-parameter mutation tool with 0% schema coverage and no annotations covering the staged-write behavior, gaps remain around keyword format, account/customer identifier roles, and duplicate handling.

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

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

Schema description coverage is 0%, so the description must compensate and it only partly does: it enumerates match_type values (Broad | Phrase | Exact) and explains confirm, but says nothing about account_id, ad_group_id, customer_id, or the keyword string format. Half the parameters remain undocumented anywhere.

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: 'Adds keywords to an ad group.' The tool name/title carries the Microsoft platform, so an agent knows it targets Microsoft Ads. However, it does not distinguish itself from the sibling add_keywords (generic) or manage_keywords, leaving the platform routing partly implicit.

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 'confirm=false = preview, confirm=true applies' line gives a real usage rule for the dry-run flow, which is the closest thing to when-to-use guidance. But it never states when to prefer this tool over add_keywords or manage_keywords, and there is no prerequisite or exclusion 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 only say readOnlyHint=false and destructiveHint=false, so the description carries real weight — and it delivers by disclosing the preview/apply semantics of confirm, plus the conditional bid adjustment triggered when bid_multiplier>0. It stops short of explaining what happens to pre-existing location targets or what the response contains.

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 tight sentences, front-loaded with the action and resource, then ID sourcing, then optional-parameter behavior. No filler. Slightly dense with parenthetical example, but every clause 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?

For a 6-parameter mutation tool with an output schema present (so return values need no explanation), the description covers the non-obvious inputs and the confirm gating. The remaining gap is whether adding a target merges with or overrides existing campaign targeting.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it specifies that location_ids are numeric Microsoft LocationIds (with a concrete example) sourced from microsoft_location_search, and defines bid_multiplier's unit (%) and confirm's effect. account_id, campaign_id and customer_id are left undefined but are self-evident identifiers.

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 ('Adds a geographic location target to a campaign') and immediately distinguishes itself from the sibling targeting tools by naming the ID namespace ('Bing LocationIds'). An agent can route here versus add_microsoft_device_target or add_microsoft_demographic_target without opening either schema.

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

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

Explicitly routes the agent to microsoft_location_search for obtaining the numeric LocationIds and explains the confirm=false/true workflow, which is the key when-to-use decision. It does not state when this tool should NOT be used (e.g. replacing existing geo targets vs. adding), so it falls short of full exclusion 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?

Goes well beyond annotations: partial-failure semantics (one bad keyword can't kill the batch), per-keyword ok/criterion_id/error returns, the 10,000-negatives-per-campaign limit, idempotency via skip_existing, and dry-run behavior when confirm=false. Annotations declare idempotentHint=false, but the description clarifies that skip_existing=true makes repeated runs effectively idempotent, which is a coherent refinement rather than a contradiction.

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

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

Front-loaded with the core action, then batched into scannable paragraphs for bulk, skip_existing, targeting, and undo. Dense but every block is load-bearing; minor redundancy between the intro and the BULK section costs it a point.

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

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

For an 8-param mutation tool with no output schema documentation in the description, every behavioral trait an agent needs is present: scope, batching, dedupe, limits, precedence, dry-run, and undo path. Nothing material is left to inference.

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 0%, so the description carries the full burden — and it delivers: per-item format ('text' or 'text|MATCH_TYPE'), comma/newline string acceptance, the 5000-item cap, skip_existing semantics, campaign_id vs ad_group_id precedence, and confirm=false dry-run behavior. All 8 params are effectively documented.

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?

Explicit verb+resource (adds negative keywords) with scope stated up front: campaign or ad group level, single or batch. An agent can distinguish it from remove_negative_keyword, list_negative_keywords, and the Microsoft/TikTok variants without inspecting schemas.

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

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

Prescribes exactly when to use bulk (more than one keyword), when to pass campaign_id vs ad_group_id (cross-negation semantics), which wins if both are given, and explicitly warns against looping. Routing to remove_negative_keyword/manage_keywords for undo is spelled out.

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

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

Annotations already declare it is a non-read-only, open-world, non-destructive write. The description adds the meaningful behavior the annotations cannot: the confirm=false dry-run switch and the hard requirement that at least one landscape + one square image + one logo be present. It does not say whether re-adding duplicates or how repeated calls behave beyond the idempotentHint flag.

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?

Every clause earns its place: purpose, eligibility stake, parameter meaning, aspect ratios, minimum requirements, and dry-run semantics, all front-loaded with no filler or repetition.

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

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

For a 6-parameter write tool with an output schema (so return values need no explanation), the description covers the asset-type semantics, the resource-name source, the eligibility requirement, and the dry-run flag. It omits permission/auth requirements and what happens to previously attached images, which would round it out fully.

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

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

Schema description coverage is 0%, so the description has to carry the load and largely does: it explains marketing_image (1.91:1), square_image (1:1), logo (1:1), states the values are asset resource_names from upload_image_asset, and defines confirm=false as dry-run. customer_id and asset_group_id are left purely to the schema, a minor gap given they are self-evident IDs.

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 ('Attaches IMAGES to a Performance Max asset group') and immediately conveys why it matters. It also names the upstream dependency (upload_image_asset) and the sibling category (PMax asset operations) an agent needs to place it correctly.

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 clear context for use (required for campaign eligibility, minimum asset mix) and explains the dry-run path via confirm=false. It stops short of naming alternatives or exclusions relative to update_pmax_assets / update_pmax_asset_group, which the agent must infer.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), so the bar is lower, yet the description adds substantial behavior: confirm=false previews vs confirm=true creates, the DNS/nameserver handoff, the explicit warning never to hand out CNAME/A records, and the no-extra-cost hosting model.

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-loaded with the core purpose and tightly written across several dense sentences; the DNS and follow-on guidance earn their place. Slightly long, with some explanatory copy ('at no extra cost') that borders on persuasive rather than operational.

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 mutating, open-world tool this is thorough: creation flow, preview vs commit, DNS responsibility, edge case, and downstream tool routing are all covered. An output schema exists, so return-value explanation is legitimately omitted.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It documents domain (new site's own domain, with example), key (optional short name, defaults to a slug), and confirm (preview vs create). However, the `server` parameter is never mentioned, leaving one of four parameters unexplained in both schema and description.

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 ('Adds ANOTHER website to the user's existing server, on its own domain') and explicitly distinguishes this from the alternative of buying a second server. It also implicitly separates itself from siblings like create_trial_site, scaffold_site, and remove_site.

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 explicit when-to-use guidance ('Use this instead of telling them to buy a second server') and routes the follow-on step to a named sibling ('Then write the pages with site_write_file'). It even covers the edge case where no registrar action is needed.

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 destructiveHint=true and idempotentHint=false, but the description adds the crucial facts beyond them: apply can trigger costly changes such as budget increases, those changes fall under the same guardrails as set_campaign_budget, and confirm=false produces a dry run. The dry-run default and cost warning are exactly the behavioral context an agent needs before a destructive write.

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?

Four terse fragments, each carrying a distinct piece of operational meaning (verb pair, parameter provenance, action values, cost/dry-run semantics). Nothing is padding and the riskiest information is front-loaded.

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

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

With an output schema present, return values need no explanation, and the description covers the write risk, the dry-run path, and parameter sourcing. It stops short of saying whether applied changes can be rolled back or how partial failures across multiple resource_names are handled.

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 0%, so the description must compensate, and it does for the two risky parameters: resource_names is described as comma-separated values sourced from list_recommendations, action is constrained to apply|dismiss, and confirm is explained as a dry-run switch. Only customer_id is left unstated, which is a minor gap given how conventional it is.

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

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

States a specific verb pair and resource ('Applies or dismisses Google recommendations'), which is far better than the title alone. The only ambiguity is the overlap with the sibling dismiss_recommendations, which the description never addresses, so an agent must guess which entry point to use for dismissal.

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 routes the agent to list_recommendations as the source of resource_names and gives the action enum values, which is concrete usage guidance. It does not say when to prefer this tool over dismiss_recommendations or list_recommendations, leaving that routing 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 flag destructiveHint=true and idempotentHint=false, and the description adds value beyond them by disclosing confirm=false = preview (a dry-run path) and the MAX_CONVERSION dependency. It does not, however, explain why the operation carries a destructive hint or what state changes when confirm=false is omitted.

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 sentences, zero filler, with the core action and its effect front-loaded, followed by parameter sourcing and the preview flag. Every sentence adds signal.

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

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

An output schema exists so return values need not be described, and the description covers the key prerequisite, the preview flag, and parameter sourcing. Missing only account/campaign identifier semantics and any permission/eligibility requirements.

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 0%, so the description carries the full burden. It explains the two non-obvious parameters (conversion_id sourced from list_linkedin_conversions, confirm as a preview toggle), though account_id and campaign_id are left to name inference.

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 (attaches), resource (conversion tracking rule), target (LinkedIn campaign), and the outcome (reporting/optimization for that conversion). It is immediately distinguishable from the sibling detach_linkedin_conversion and list_linkedin_conversions.

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 clear usage context: an existing rule must be attached to a MAX_CONVERSION campaign before it can go ACTIVE, and conversion_id comes from list_linkedin_conversions. It stops short of naming an explicit alternative or when-not-to-use condition, but the routing guidance is strong.

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 carry readOnlyHint/idempotentHint, so 'READ-ONLY' adds little, but the description usefully defines the projected behavior (month-end spend projection), the meaning of the over/under flags, and the pace_pct formula. It stops short of stating time-range or account-scope constraints beyond customer_id.

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 tool identity in caps, then the computation, then the flag semantics, then the parameter note. Dense and largely waste-free, though the em-dash fragments and trailing parameter/formula notes read as terse rather than cleanly structured.

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 need not enumerate return fields, and it still explains what the flags mean and how pace_pct is derived. What is missing is scope/permission context (which ad platforms, what customer_id refers to) and any indication of result volume.

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

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

Schema description coverage is 0% with 2 parameters, so the description must compensate. It defines threshold_pct as the deviation threshold in percent (consistent with the schema default of 20), but customer_id is never explained and pace_pct is an output field, not an input.

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: projects this month's spend against daily budget and flags over/under-spending campaigns. That is clearly distinct from write siblings like set_campaign_budget or reporting siblings like performance_report, 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?

The description explains what the tool computes but gives no when-to-use guidance, no prerequisites (e.g. account must be connected), and no routing away from alternatives such as performance_report or get_report. Usage is only inferable from the purpose sentence.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: the preview is appearance-only and does not prove eligibility to serve, which is a real semantic caveat an agent would otherwise get wrong.

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 paragraphs, front-loaded with what the tool does before the caveat about eligibility. The second paragraph is slightly discursive but each sentence carries a distinct point (appearance-only, not proof of eligibility, adds serving issues).

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 supplies the key behavioral caveat, but its silence on the two input parameters is the one material gap for calling it 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 0% for two parameters, and the description never mentions ad_id or the optional account parameter. ad_id is inferable from the name, but account's purpose and default behavior are undocumented in both the schema and the description, leaving the agent without compensation for the coverage gap.

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

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

The description names a specific verb and resource ('renders how an existing ChatGPT Ads ad looks') and clarifies the additional payload (delivery blockers and review status). It distinguishes itself from a pure rendering tool by stating it does NOT prove eligibility, but it never names the closely-related siblings (chatgpt_ads_details, diagnose_chatgpt_ads_delivery) it could be confused 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?

It gives a clear use context — this is what 'actually answers why is this not running' — which implies when to reach for it. However, it names no alternatives and gives no when-not-to-use guidance, so the agent must infer its place among chatgpt_ads_status and diagnose_chatgpt_ads_delivery.

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?

Despite annotations already declaring it read-only and idempotent, the description adds substantial behavioral context beyond them: the 50-event / ~15-minute window, the pixel_sdk vs server_to_server channel labels, that an empty list only means nothing arrived in that window, and that a 404 is surfaced when OpenAI has not enabled the stream. It also distinguishes standard (usable as a campaign goal) from custom (measure-only) events.

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 content is dense but well ordered: purpose first, then the questions it answers, then the caveats about the test stream and 404. No sentence is filler, though the parenthetical channel details make it longer than strictly necessary.

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 description covers the important edge cases (empty window, disabled stream). The one real gap is that the `account` parameter is never addressed, leaving the agent to infer which account is queried.

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

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

Schema description coverage is 0% and neither parameter is named in the description; the `account` parameter is never explained at all. The discussion of recent events implicitly maps to `check_recent_events`, but the description does not compensate for the documentation gap on account scoping or on how the two parameters interact.

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

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

The description states a specific verb and resource set: it shows conversion tracking pixels (data sources), event settings and their attached campaigns, plus recently received events. That is much more specific than the title. It does not, however, explicitly differentiate itself from near-siblings like chatgpt_ads_details or conversion_tracking_health, so a 4 rather than 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?

It gives concrete usage contexts in the form of the questions it answers ("is my pixel firing", "which campaigns measure which action"), which tells the agent when to reach for it. It stops short of naming an alternative tool or stating when not to use it, so no exclusions are provided.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, so the bar is lower. The description still adds real value beyond them: the entity-type field inventory, pagination behavior for context hints, and especially the 24-hour bid_too_low caveat explaining when the value becomes evaluable.

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-loaded with the core purpose before the per-entity breakdown, and the structure is scannable. It is on the long side and 'including everything that decides delivery' is slightly padded, but every substantive clause (prefixes, caveat, paging) 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?

An output schema exists, so return-value detail is not strictly required, yet the description usefully previews it. Given four parameters at 0% schema coverage, the only real gap is the unexplained `account` parameter; otherwise the definition is complete for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry the load. It does well for id (revealing the cmpn_/adgrp_/ad_ prefix convention, which is critical for correct invocation) and for hints_limit/hints_offset paging, but the `account` parameter is never mentioned, leaving one of four parameters undocumented.

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

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

The description states a specific verb and resource ('Full details of one ChatGPT Ads campaign, ad group or ad by id') and enumerates exactly what 'details' means for each of the three id prefixes. This cleanly separates it from list_*/create_*/update_chatgpt_ads_* siblings without needing to name 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 implied by 'full details of one ... by id' — the agent can infer it is a single-object read. But no explicit when-to-use guidance or alternatives (e.g., chatgpt_ads_status, chatgpt_ads_insights) are named, leaving the agent to guess which read tool to pick.

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

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

Annotations already declare readOnlyHint/idempotentHint, so the trailing 'Read-only' is redundant, but the description adds real behavioral context beyond them: the ambiguous country-name matching against postal codes and the fact that a valid location id does not imply ad eligibility under OpenAI policy. That is genuinely useful pre-call knowledge.

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?

Four sentences, front-loaded with the purpose and the chaining target, then caveats. Dense but each sentence carries information; the only waste is restating 'Read-only' already covered by annotations.

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 documentation is not strictly required, yet the description still usefully sketches the returned fields for chaining. It covers the ambiguity and policy gotchas an agent needs; only the limit/account parameters remain 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 description coverage is 0%, so the description must carry the param burden. It does explain the query parameter well (English/local names, ISO codes like TR), but says nothing about the limit or account parameters, leaving two of three undocumented in both schema and description.

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 (finds) and resource (ChatGPT Ads location ids) plus the enumerated location types. It is clearly distinguishable from the many sibling geo tools (geo_target_search, microsoft_location_search, tiktok_region_search) by naming the ChatGPT Ads platform 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?

Explicitly names the downstream consumption path (pass the id or ISO code to update_chatgpt_ads_campaign include_locations/exclude_locations), tells the agent what input forms work (English or local name, ISO code), and warns about the postal-code false-match and the pilot-country/category-policy caveat. When-to-use and when-not-to-trust are both covered.

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 carry readOnly/idempotent/non-destructive, and the description confirms read-only while adding real behavioral context beyond them: hourly history limited to ~30 days, timestamps in the account time zone, currency for spend/CPC/CPM, conversion lag ('settle over about a day') and the null-vs-zero distinction. Missing only data freshness/pagination limits beyond what limit/offset imply.

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-loaded with the purpose, then organized clause-by-clause around parameters, with zero filler sentences. It runs long, but nearly every clause encodes a constraint or behavior an agent needs, so the density justifies the length.

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

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

For a 12-parameter analytics tool with an output schema, the description covers scope, level, granularity, segmentation, zero-impression semantics, conversion caveats, time zone, currency, date handling and paging. Nothing required for a correct invocation 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 coverage is 0% with 12 parameters, so the description carries the full load and does so: scope_id prefixes (cmpn_/adgrp_/ad_), level values, granularity values with history caveat, segment enum values (android_app, ios_web, etc.) that the schema lacks, date format and defaults, and paging via limit/offset.

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?

Names a specific artifact (ChatGPT Ads delivery report) and enumerates the dimensions it reports (time buckets, breakdowns, zero-impression rows, conversions), which clearly separates it from siblings like chatgpt_ads_details, chatgpt_ads_status and diagnose_chatgpt_ads_delivery.

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?

Explains when to reach for each option, including the diagnostic use case ('include_zero=true ... is how you see what is NOT delivering') and incompatibility rules (segment not with hourly or conversions; conversions only at granularity none/daily). It does not, however, state when to prefer this tool over sibling reporting tools such as diagnose_chatgpt_ads_delivery.

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?

Far exceeds what the annotations provide. Annotations only declare safe/idempotent/read-only; the description adds the auth requirement (ad-account ADMIN key with billing permission), the graceful non-failure behavior for ordinary keys ('says exactly that instead of failing'), the billing-plan restriction (postpaid invoice only), currency units, and exclusive end-date semantics in the account time zone. This is exactly the operational context an agent needs to interpret a result or an unexpected response.

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

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

Four dense but front-loaded sentences: what it shows first, then the account-vs-campaign caveat, then data semantics, then auth. Every clause except the trailing 'Read-only' earns its place; that last sentence duplicates readOnlyHint and could be dropped. No filler otherwise.

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 needn't be described, and the description covers currency, date exclusivity, billing-plan scope, and auth behavior thoroughly. The one real gap is the unexplained `account` parameter, which matters because the tool is account-scoped.

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?

There is one parameter, `account`, with 0% schema description coverage and a bare empty-string default, so the schema does not carry the burden — this is not the zero-parameter baseline-4 case. The description never explains what `account` accepts or what the empty default resolves to (all accounts? default account?), leaving the agent to guess how to target an account.

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 ('Shows the ChatGPT Ads account-level spending limits') and enumerates what is returned: date-range windows, recurring daily limit, spend so far. It also draws the crucial account-vs-campaign scope boundary, which is what separates it conceptually from the campaign budget tools. It does not name the obvious sibling `manage_chatgpt_ads_spend_limit` (the write counterpart), so the read/write routing is only implied by 'Read-only'.

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 concrete when-it-matters context: an account limit caps spend across ALL campaigns, so a campaign can have budget left and still stop — this tells an agent exactly which diagnostic question this tool answers. It also states preconditions (admin key with billing permission, postpaid/invoice billing only), which is strong usage guidance. It stops short of naming the alternative tool to use for changing limits.

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?

Goes well beyond the destructiveHint/openWorldHint annotations: it warns that archiving is not reversible via the API, states that confirmation is required, and describes the two-mode behavior (confirm=false dry-run naming what will change vs confirm=true applying and reading back to verify). This is exactly the behavioral context an agent needs before a destructive write.

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?

Well front-loaded: the primary action leads, followed by the parameter enums, then the confirm workflow, then account scoping. Every sentence adds information, though the backtick-heavy formatting is slightly dense for prose.

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 destructive multi-entity mutation tool, the description covers actions, target kinds, confirmation flow, reversibility, and account scoping thoroughly. An output schema exists so return values need no explanation, leaving no material gap for an agent to call this safely.

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

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

Schema description coverage is 0% and no enums are defined in the schema, so the description carries the full burden; it supplies the allowed values for `kind` and `action`, explains `account` semantics and its default-account behavior, and documents `confirm`'s dry-run meaning. Only `id` is left unexplained, which is minor and self-evident.

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 specific verbs (pauses, activates, archives) and the exact resource scope (ChatGPT Ads campaign, ad group, or ad), and the enum framing for `kind` resolves the ambiguity of the generic name 'status'. An agent can immediately tell this is a status-mutation tool rather than a status-reader like chatgpt_ads_details.

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

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

The description explains the confirm dry-run/apply workflow and how to select account, which is genuine usage guidance, but it never says when to use this versus siblings such as update_chatgpt_ads_campaign, update_ad_status, or pause_campaign. Usage is implied by the action enums rather than stated explicitly.

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, non-destructive and closed-world, so the description's 'READ-ONLY' line is largely redundant. It does add one useful behavioral fact — brand_name appears in the report title — but says nothing about permissions, latency, or whether the report is generated on demand.

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

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

One dense, front-loaded sentence that puts the tool's identity and the sibling alternative in the right order. It is information-rich rather than padded, though the em-dash stacking makes it slightly heavy for a single sentence.

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

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

An output schema exists, so return values need not be spelled out, and the description still previews the KPI set. Combined with annotations covering safety, the definition is complete enough for an agent to invoke it 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 coverage is 0%, so the description must carry parameter meaning and it only partially does: it explains brand_name's effect on the title and implies days through 'period performance' vs 'previous period'. customer_id (the required parameter) and the exact meaning/default of days are left undocumented.

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 (aggregates an account's period performance) and enumerates the exact outputs (cost/clicks/conversions/ROAS/CPA/CTR plus % change vs previous period). It explicitly distinguishes itself from the sibling client_report_link by labeling the latter the 'shareable page' option, so an agent can route correctly without opening a 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?

Gives a clear usage context (agency, white-label, client-ready) and names the alternative with a condition: 'For a shareable page, use client_report_link.' However it offers no when-not guidance (e.g., when a raw internal report is preferable) and does not describe account/period selection beyond defaults.

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 declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true. The description helpfully discloses the snapshot write and the public (open-world) URL, but leads with 'READ-only (+ stores a snapshot)', which is at odds with readOnlyHint=false, and never explains the destructiveHint=true implication (e.g. what an existing snapshot is replaced or what is overwritten). The tension is compounded by an unexplained destructive flag.

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-loaded with the key differentiator (public shareable link) and compact. Some redundancy in the all-caps framing and the trailing 'READ-only (+ stores a snapshot)' clause dilutes rather than informs.

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. However, for a tool with a hidden write side effect (snapshot storage, destructive flag) and zero parameter documentation, the description leaves important operational context 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 0% for three parameters. The description only clarifies one: brand_name appears in the report title. Neither `days` (default 30) nor `customer_id` (required) is given any meaning, so the description does not compensate for the empty 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 concrete verb+resource combination: it generates client_report, freezes a snapshot, and returns a public URL. This is clearly distinct in output shape from the sibling `client_report`, though the description never names that sibling to draw the contrast 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 phrase 'a page URL you can send to your client' implies the use case (client-facing deliverable), but there is no explicit when-to-use/when-not guidance and no routing away from the closely related `client_report` sibling. Usage must be inferred.

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

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

Annotations already declare readOnly/idempotent/open-world, so safety is covered. The description adds real value beyond them: the data is LIVE from public ad libraries, only publicly available creatives/copy are returned, and the Meta path requires a connected account (auth prerequisite).

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-loaded with the core purpose, then platform details and the negative-keyword caveat. Dense but each clause contributes; the platform list is compact and readable.

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?

Output schema exists so return format needn't be described, and annotations cover the safety profile. The description supplies the important operational caveats (live public data, auth requirement for Meta), leaving only the non-platform parameter semantics thin.

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 0%, so the description carries the param burden. It documents the platform enum values well and implies the query is a brand/domain, but leaves limit and region (default TR) entirely unexplained. Partial compensation only.

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 (fetches) and resource (a brand's/domain's LIVE ads from public ad libraries), with the platform scope enumerated (google/meta/linkedin). It is clearly distinguishable from sibling data tools like seo_paid_keywords or keyword_opportunities because it targets competitors' live ad creatives from public libraries.

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 clear context for each platform path, including the prerequisite that meta requires a connected Meta account, and a useful exclusion (competitors' organic keywords are NOT available). It stops short of naming a specific alternative tool to use instead for organic keywords, so no explicit 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?

Goes far beyond the annotations (destructiveHint=true, idempotentHint=false): password stored encrypted, only the owner's fixed to_email receives mail, honeypot anti-relay protection, default test email, 20/hour rate limit with 429, GET returns 404/405 by design, no JSON body accepted, no CORS headers, and 502 when the mail account refuses. Consistent with the destructive/idempotent hints (re-running reconfigures the same form).

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?

Long and dense, but the length is justified by a genuinely complex tool (10 params, relay semantics, endpoint field contract, rate limits). It is mostly front-loaded, though the endpoint-contract material is jumbled into the same paragraphs as the config guidance rather than separately structured.

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 (endpoint URL + HTML snippet) need no further unpacking, and the description still delineates the endpoint field contract, redirect semantics, and failure modes. Nothing an agent needs to invoke 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?

With 0% schema coverage on 10 params, the description compensates well: provider values and ports ('yandex' smtp.yandex.com:465, 'gmail' requires an app password, 'other' needs smtp_host+smtp_port), from_email alias constraint, to_email as fixed recipient, send_test default, and the read-only trigger via smtp_user/smtp_pass. Minor gap: `subject` and `smtp_user` are not clearly explained as configuration parameters.

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 (sets up a contact-form→email relay for the user's hosted static site) and makes the mechanism explicit (form POSTs to a thin relay forwarded through the user's own Gmail/Yandex). It is clearly distinguishable from siblings like wordpress_contact_forms and create_lead_form.

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 explicit when-to-use modes: read-only mode ('call with only `server` ... to see whether that site's form is already set up') versus full setup, plus the static-site scoping that separates it from WordPress/CRM form tools. It stops short of naming a sibling alternative for non-static sites, so it falls just under 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 readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false. The description adds meaningful context beyond annotations: the authorization link is stored with a separate encrypted token and does not affect the Google Ads connection, which is important for an authentication/connect tool.

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

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

The description is two sentences and front-loads the core action: generating an authorization link. Every clause adds relevant information about scope and behavior, 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?

For a no-parameter connection tool with an output schema and annotations, the description is largely complete. It explains what is generated, what capabilities the connection enables, and how the token is isolated, though it could mention any prerequisite admin access or authorization flow details.

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

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

The tool takes no parameters, so the baseline of 4 applies. There are no parameter semantics to document, and the description correctly does not invent or omit any parameter details.

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: generating an authorization link to connect Google Business Profile. It also names the enabled capabilities (editing business info/hours/website, publishing posts, replying to reviews) and explicitly distinguishes the tool from the Google Ads connection, making it easy to tell apart from sibling connect_* tools.

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

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

Implies the context clearly: use this to connect a Google Business Profile account. It provides a useful exclusion by noting it does not touch the Google Ads connection, which helps route away from connect_google_ads, but it does not explicitly state when to choose this over other GBP-related tools or list prerequisites.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), the description discloses that the link is one-time, that the token is separately encrypted, and that it does not touch other platform connections. These are useful behavioral details not encoded in the structured fields.

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 core action is front-loaded in the first sentence, but the second sentence is long and lists read/setup capabilities that are handled by sibling tools, so it does not fully earn its place in a connect tool 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?

For a 0-parameter connect tool with an output schema and annotations, the description covers the purpose, one-time link, and token isolation. But it fails to route the agent to the actual read/setup tools and instead claims those capabilities, leaving a meaningful gap in context.

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

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

The tool has zero parameters and an empty schema, so the baseline is 4. The description does not need to explain parameter behavior, and it adds no misleading parameter information.

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 first sentence gives a concrete verb and resource ('Generates a one-time authorization link to connect Google Analytics 4'), but the second sentence claims the tool READS reports and lets you set up GA4 — functions that belong to sibling tools like ga4_report, ga4_create_conversion, and ga4_link_google_ads. That conflation muddies the selection signal even though the core connect action is 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?

It implies the usage context by naming the connection purpose and scoping it away from Ads, Search Console, and Business Profile connections. However, it never says when to use this tool versus ga4_report or other connect_* siblings, and it names no explicit 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 non-read-only, non-idempotent, non-destructive, non-open-world behavior. The description adds genuinely useful context beyond that: the link is one-time, requires the user to click and approve with Google, and the resulting refresh token is stored encrypted. It does not mention link expiry or re-issuance.

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, front-loaded with what the tool produces and followed by the post-approval consequence. Every clause earns its place; 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?

For a zero-parameter OAuth-initiation tool with an output schema (so return shape needn't be described) and full annotation coverage, the description is nearly complete. It omits only peripheral details like link lifetime, required user permissions, and what happens on repeat calls.

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

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

The tool takes zero parameters, so the schema has nothing to document; per the baseline for a parameterless tool, a 4 applies. The description correctly adds no parameter detail because none exists.

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 ('Generates') and a precise artifact (a one-time authorization link for a Google Ads account), plus the outcome of the flow. It is clearly distinct from connect_meta_ads/connect_ga4 by resource, though it never explicitly contrasts itself with 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 implied: call this when a Google Ads account needs to be connected, and the two-step click/approve flow is described. However, there is no explicit when-not guidance, no mention of prerequisites or of alternatives such as create_google_ads_account or select_google_resource.

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 establish the non-read-only, non-destructive, non-openWorld profile. The description adds genuinely non-obvious behavior beyond them: the link is one-time, a user must click and approve externally, and the resulting token is stored encrypted. It stops short of stating idempotency/link expiry, which would round it out.

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

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

Two sentences, zero filler, with the primary effect (generating the link) front-loaded and the consequence (approval flowing into encrypted token storage) second. Every clause earns its place.

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

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

For a zero-parameter tool with an output schema covering return values, the description supplies the essential context an agent needs: the tool produces an authorization URL and hands control to the user. It could note what happens on re-invocation, but nothing critical 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?

The tool takes zero parameters, so per the baseline there is nothing for the description to document. The 100% schema coverage is vacuous but the description correctly implies no inputs are needed.

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 (generates an authorization link) and resource (LinkedIn ad account), plus the end outcome (token stored). It is clearly distinguishable from the large connect_* family and from list_linkedin_ad_accounts, which require an already-connected account.

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

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

The description implies usage by describing the flow but never states when to call it (e.g., before any LinkedIn Ads operation) or what to do if the account is already connected. With ~15 connect_* siblings, explicit routing guidance would have been valuable.

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?

Beyond the annotations' safety hints, the description adds important behavioral context: the authorization link is one-time, the token lasts 60 days, no refresh token is issued, and reconnection requires this same tool. These details are essential for correctly using and revisiting the connection.

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

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

The description is two tightly written sentences. The core action is front-loaded, and the token-lifetime caveat is placed immediately after without any 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?

Given the tool has no parameters and an output schema is provided, the description covers what the agent needs: what the tool does, what it returns conceptually (an authorization link), and the token lifecycle limitation. Nothing essential 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?

The tool has zero parameters, so the schema has nothing to document and the description appropriately does not discuss parameter semantics. The baseline for a no-parameter tool is 4.

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 ('Generates') and resource ('one-time authorization link to connect a Meta (Facebook/Instagram) ad account'), making the tool's purpose immediately clear and distinguishable from other platform-connection 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?

It clearly implies the primary usage context — connecting a Meta ad account — and explicitly tells the agent to reuse the same tool when the token expires. It does not name alternatives or when-not conditions, but the reconnection guidance is concrete.

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 the safety profile (readOnly=false, destructive=false, idempotent=false), so the bar is lower. The description still adds valuable behavior beyond the schema: the link is ONE-TIME (matching idempotentHint=false) and the post-authorization outcome is querying accessible ad accounts. It omits link expiry, permission requirements, and what happens on re-invocation.

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

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

Two short sentences with the primary action front-loaded and the follow-on capability second. Nothing is 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 only zero parameters and an output schema that documents the returned link, the description covers the essential purpose and the downstream flow. It could go further by noting the link must be surfaced to the user for authorization and that it expires/single-use, 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?

The tool takes zero parameters, so per the baseline a 4 applies. There is no parameter surface for the description to compensate for, and it correctly describes the no-argument behavior (generates a link, no inputs).

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

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

States a specific verb and resource ('Generates a one-time authorization link to connect a Microsoft Advertising (Bing Ads) ad account') and disambiguates from sibling connect_* tools by naming the platform. An agent can tell this apart from connect_google_ads or connect_meta_ads without opening any schema.

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

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

The description implies the usage context (use this to establish the connection, then you can query accounts) but never states when-not-to-use it, e.g., what to do if the account is already connected or that list_microsoft_accounts should be used afterward. No prerequisites or alternative routing are given.

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 supply the safety profile (readOnlyHint=false, idempotentHint=false, non-destructive). The description adds meaningful context beyond them: the link is one-time, credentials are stored under a separate encrypted token, and the Ads connection is untouched. It does not explain link expiry handling or whether re-invocation regenerates the link, which idempotentHint=false suggests matters.

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

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

Two sentences, front-loaded with the core action and scope, then a second sentence covering the two things an agent would otherwise have to guess (token isolation, non-interference with Ads). 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 values need not be described, and the description covers the operation's scope and its key boundary (Search Console only, not Ads). What remains thin is the follow-through: nothing about how the returned link is consumed or what state the account must be in beforehand.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and schema coverage is 100%.

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 (generates) plus resource (one-time authorization link for Google Search Console), and enumerates the data scope it unlocks: organic queries/clicks/impressions/position, sitemap management, URL index inspection. An agent can distinguish it from the many connect_* siblings (connect_google_ads, connect_ga4, etc.) without opening any 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?

Usage is implied — call it to link Search Console — and it helpfully notes it is separate from the Google Ads connection, which partially routes the agent away from connect_google_ads. However, it never explicitly states when to use this versus other connect tools, nor any prerequisites (admin access, which account must be selected first). Guidance is inferable but not spelled out.

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

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

Annotations already declare the non-read-only, non-idempotent, non-destructive profile. The description adds real value beyond that: the link is one-time, the credential is stored as a separate encrypted token, and the scope of granted access is enumerated. It stops short of describing the auth flow steps or link expiry window.

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 dense sentences, front-loaded with the core action, then the scope breadth, then the isolation constraint. Every clause carries distinct information with no padding.

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

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

With an output schema present, return values need not be explained, and the description covers the auth behavior, credential storage, and scope boundaries. Complete enough for a parameterless connect tool, though it could note what the returned link looks like or how long it is valid.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter syntax for the description to compensate for.

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 ('Generates a one-time authorization link to connect Google Tag Manager') and immediately scopes the breadth of access ('full A-to-Z management'). It also explicitly distinguishes itself from the many connect_* siblings by naming what it does NOT touch.

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 scope statement ('does NOT touch the Google Ads / Search Console / Business Profile / Analytics / YouTube connections') cleanly routes the agent among the crowded connect_* family. It lacks an explicit 'use this when the user wants to connect GTM' phrasing or prerequisites, but the alternative-isolation is clear enough to select 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 establish the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds meaningful behavior beyond that: the link is 'one-time', which explains why the operation is non-idempotent, and it describes the downstream flow to advertiser accounts. It stops short of describing auth requirements or link expiry.

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 zero filler; the core action (generating the auth link) is front-loaded ahead of the follow-up context. Every clause earns its place.

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

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

With an output schema present, return-value detail is not required, and for a zero-parameter tool the description covers purpose and the natural next step. It is nearly complete, missing only minor behavioral detail such as link expiry or permission prerequisites.

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

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

The tool takes zero parameters (schema coverage trivially 100%), so there is no parameter semantics to convey and the baseline of 4 applies. The description correctly adds nothing about inputs since none exist.

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

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

States a specific verb ('Generates a one-time authorization link') and resource ('a TikTok ad account'), so the agent knows exactly what the tool produces. The TikTok platform qualifier separates it from the many other connect_* siblings, though it never names an alternative 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 second sentence implies usage context by noting that after authorization you can query accessible ad accounts (advertisers), essentially pointing to list_tiktok_ad_accounts. However, it gives no explicit when-to-use/when-not guidance or named alternative, leaving the routing inference to the agent.

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?

Adds real behavior beyond annotations: a one-time link, a separate encrypted token, and isolation from other platform connections. Note the surface tension with readOnlyHint=false — the description's 'read-only' refers to the granted YouTube data scope, not the operation, which itself creates a token/connection; this is not an actual contradiction. It doesn't explain link expiry or what happens on re-run.

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 clauses with zero filler, front-loading the primary action and following with the scope and isolation guarantees. Every fragment 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?

With annotations present, an existing output schema, and no parameters, the description covers what the connection grants and how it is isolated. Adequate for an agent to decide and call it; only the mechanics of the link lifecycle are left implicit.

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

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

Schema coverage is 100% and the tool takes zero parameters, so there is nothing for the description to compensate for. This is the expected baseline for a parameterless tool.

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 precise verb+resource ('Generates a one-time authorization link to connect YouTube') and immediately scopes the connection ('channel + video performance: views, watch time, subscribers, traffic sources — read-only'). An agent can distinguish it from the other connect_* and youtube_* siblings without opening a schema.

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

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

The second clause carves out clear boundaries against alternatives by naming what it does NOT touch (Ads / Search Console / Business Profile / Analytics connections). This gives strong context for choosing this connection over the others, though it stops short of an explicit 'use this when you need YouTube data' trigger.

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, closed-world), so the bar is lower. The description still adds real value beyond them: the include_in_conversions_metric vs. misleading legacy primary_for_goal semantics, the zero-conversion alert condition, and the note that the UI 'Tracking status' diagnostic is not a single API field.

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 purpose and then layers the field-semantics caveats; every sentence is information-bearing rather than filler. It is dense and somewhat long, but the detail is justified given the confusing underlying fields.

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

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

An output schema exists, so return values need not be described. Given the complexity of conversion-status semantics, the description supplies exactly the caveats needed for correct interpretation and points to the sibling for detail work, leaving no critical gap.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains days well ('lookback window for the conversion-volume check, default 30'), but customer_id is left undocumented in both schema and description. Partial compensation for a low-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?

States a specific verb and resource ('audits conversion actions') and immediately scopes the check to paused/removed actions and zero-data over the lookback window. It clearly differentiates itself from the sibling list_conversion_actions by naming it as the tool for the full per-action table.

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 the agent: 'for the full per-action table use list_conversion_actions', establishing when to use this narrow health check vs. the sibling listing tool. It also clarifies the alert logic (zero-conversion alerted ONLY for Primary/included actions), removing the main ambiguity an agent would face.

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 non-read-only, non-destructive mutation, but the description adds substantial context beyond them: the copy is created PAUSED, deep-copy is limited to 3 objects per call (error 100/subcode 1885194), the tool auto-chunks oversized deep copies and reports deep_copy:'chunked', and rename_prefix behavior is described.

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-loaded with the core action before edge cases, and each sentence adds distinct information (paused state, limit, chunking, preview). It is dense and slightly long, 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, so return-value explanation is unnecessary, and the description still notes the result reports chunked versus non-chunked copies. For a 6-param mutation tool it is nearly complete, with only the obvious account/entity identifiers and connection prerequisites 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 coverage is 0%, so the description must carry the load; it documents meaningful semantics for kind, deep_copy, rename_prefix, and confirm (including default-driven preview behavior). account_id and entity_id are left implicit, but they are self-evident identifiers, so this is a strong rather than complete compensation.

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 ('Copies a Meta campaign/ad set/ad') and anchors it to the real-world Ads Manager 'Duplicate' action, which removes any ambiguity for an agent choosing among the many create_/update_/delete_meta_* 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?

Explains when deep_copy applies (campaign/ad set with children), what confirm=false does, and the valid kind values, giving clear context for invocation. It does not explicitly name an alternative tool (e.g., create_meta_campaign) for cases where duplication is not wanted, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial value beyond them: no credit cost, the two data sources (lab + CrUX field), and a detailed account of what resources=true changes—raw resource lists, unused CSS/JS bytes, oversized images, network requests, LCP element—with the consequence of omitting it.

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-loaded with purpose and the free/no-credit hook, and every sentence about resources genuinely earns its place given the 0% schema coverage. The middle paragraph is dense but not padded, so it is appropriately sized rather than excessively verbose.

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

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

An output schema exists, so return values need no explanation; safety is covered by annotations; and all non-trivial parameters are explained. Nothing an agent needs 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 0%, so the description carries full burden and does so: strategy accepts 'mobile' (default) or 'desktop', resources toggles raw resource output, and limit caps rows per audit with default 20. Only url is left implicit, which is self-evident from the tool's purpose.

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 ("Real Core Web Vitals & performance for a page") and names the underlying source and metrics (Google PageSpeed Insights, LCP, CLS, INP/TBT, 0–100 score, opportunities). It is clearly distinguishable from adjacent siblings like seo_technical_audit or wordpress_performance.

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

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

Gives a concrete when-to-use context ("quality gate when building or fixing a website") and notes it is free with no credit cost. It does not explicitly name an alternative tool or state when NOT to use it, so it stops short of the top band.

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 the safety profile (readOnly=false, destructive=false, idempotent=false), lowering the bar. The description still adds non-obvious behavior: confirm=false triggers a dry-run, and the call returns an ad_group_id that downstream tools require. It does not cover auth scopes or rate limits, but the dry-run default is the key behavioral disclosure.

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

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

Purpose is front-loaded in the first sentence, followed by workflow context and parameter notes. The arrow-chain sentence is dense but each tool it names earns its place by disambiguating the sequencing, and there is 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 values need no prose explanation, and annotations carry the safety profile. For a create tool with a clear workflow and the two tricky params documented, an agent has everything needed to invoke it 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 coverage is 0%, so the description must compensate. It explains the two ambiguous params well — cpc_bid as the group's default max CPC in account currency, and confirm=false as dry-run — while customer_id, campaign_id, and name are self-evident from their names, so the remaining gap is minor.

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

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

States a specific verb and resource ('Creates a new AD GROUP inside a Google Ads campaign') and immediately scopes it ('the layer between the campaign and its keywords/ads'). The Google Ads qualifier cleanly distinguishes it from siblings like create_microsoft_ad_group, create_tiktok_adgroup, and create_meta_adset.

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 places the tool in an end-to-end workflow (create_search_campaign → create_ad_group → add_keywords → create_responsive_search_ad), naming the sibling tools it depends on and follows. It also gives the 'one per theme' heuristic, so an agent knows both when and how often to call it.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), but the description adds real behavioral context beyond them: the campaign is created in PAUSED state and confirm=false triggers a dry-run. These are meaningful operational traits an agent needs.

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?

Extremely terse and front-loaded: verb+resource first, then parameter clarifications, then dry-run behavior. Every clause carries information, though the telegraphic style borders on under-specification for a 7-parameter write tool.

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

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

An output schema exists so return values need no explanation. However, for a mutation tool creating a campaign with required budget and targeting-adjacent params, the description says nothing about budget units, target_cpa meaning, or the customer_id scope, leaving gaps an agent would need to guess at.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate. It clarifies three parameters (app_id as store app ID, app_store enum values, confirm dry-run semantics) but leaves name, customer_id, daily_budget, and target_cpa unexplained. Partial compensation.

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

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

States a specific verb and resource: 'Creates an App (UAC) campaign'. The 'App (UAC)' qualifier distinguishes it from sibling campaign creators like create_search_campaign, create_demand_gen_campaign, and create_pmax_campaign, though it does not name them 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 the brief operational notes (dry-run via confirm=false, created PAUSED), but there is no explicit when-to-use or when-not-to-use guidance relative to the many other create_*_campaign siblings. An agent must infer platform routing from 'App (UAC)'.

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=false, openWorld=true, idempotent=false, and destructive=false, but the description adds critical hidden behavior: image_url is fetched/uploaded automatically, an image is required despite the schema marking it optional, creating submits the creative for review, the ad is created paused unless activate=true, and confirm=false returns a dry run. This is exactly the extra context an agent needs to invoke the tool safely.

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-loaded with the core purpose, then moves through concise operational details with no redundant sentences. The length is appropriate for a creation tool with several hidden rules and a dry-run mode.

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

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

An output schema exists, so return values need not be described, and annotations already cover the safety profile. However, with 0% schema coverage across 9 parameters, missing explanations for name and account and no explicit sibling routing leave minor gaps for an agent.

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

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

With 0% schema description coverage across 9 parameters, the description must compensate and mostly does. It clarifies title, body, target_url, image_url, confirm, and activate semantics, but name and account remain unexplained. The important creative and control parameters are covered, though two parameters lack any definition.

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 (creates) and resource (ChatGPT Ads ad / chat card) scoped inside an ad group. Distinguishes clearly from create_chatgpt_ads_ad_group and create_chatgpt_ads_campaign, and from other platform-specific ad creation tools, by naming ChatGPT Ads ad.

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

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

Provides useful operational context: requires an ad group, image is required for a chat card, and creative should be final before submission. However, it does not explicitly say when to use this versus update_chatgpt_ads_ad, chatgpt_ads_ad_preview, or other ad creation tools. The dry-run behavior is noted but not framed as an alternative 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 only supply the generic safety profile (not read-only, not idempotent, not destructive), while the description adds substantial behavior: the two bid-validation rules, the allow_high_bid escape hatch, the meaning of context_hints, the default paused state, and dry-run via confirm=false. This is rich disclosure well beyond what the structured fields 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?

Purpose is front-loaded and follow-on sentences are dense with decision-relevant detail rather than filler. It is longer than typical, but each sentence adds binding rules or defaults, so the length is mostly earned.

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 description covers the risky mechanics (bidding, dry-run, activation default) for this mutation tool. Remaining gaps are the undescribed name/account/campaign_id params and the parenthetical treatment of billing_event.

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 0% schema description coverage, the description must carry parameter meaning, and it does so for the non-obvious ones: max_bid (currency, per-click vs per-impression), billing_event behavior, context_hints (natural-language, up to 2000, not keyword match), allow_high_bid, activate, and confirm. It leaves name, account, and campaign_id undefined, but those are largely self-evident.

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 ("Creates an ad group under a ChatGPT Ads campaign") and locates it in the campaign hierarchy, which distinguishes it from create_chatgpt_ads_campaign and create_chatgpt_ads_ad. It also names the two things it configures (max bid and context hints), so an agent knows exactly what this call produces.

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 through operational notes ("Created paused unless `activate=true`", "confirm=false returns a dry run"), which tells the agent how to invoke safely but not when to prefer this tool over siblings like create_ad_group or update_chatgpt_ads_ad_group. No explicit when-to-use/when-not or alternative routing is given.

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

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

With only a generic annotation set (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description carries the real behavioral detail: campaigns are created PAUSED, activate=true starts immediate spend, budget safety caps reject mistyped amounts rather than overspending, and confirm=false returns a dry run. This is exactly the beyond-annotations context the dimension rewards.

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 paragraphs, each front-loaded with its key constraint (budget units, then objective values, then the paused/activate warning, then the dry-run note). No filler sentences.

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, yet the description adds the dry-run response behavior anyway. All the operational facts an agent needs to avoid accidental spend and to correctly sequence creation are present.

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

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

Schema coverage is 0%, so the description must compensate, and it does for most parameters: budgets are in account currency (not micros) with conversion handled internally, objective enumeration is spelled out as clicks | reach | conversions (the schema declares no enums), and activate/confirm semantics are explained. It does not clarify 'name' or the 'account' parameter, leaving two of seven undocumented.

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 ('Creates a ChatGPT Ads campaign') and scopes it to the connected ChatGPT Ads account. It further distinguishes itself from the sibling creation tools by naming create_chatgpt_ads_ad_group and create_chatgpt_ads_ad as the follow-on pieces required under the campaign.

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

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

Gives explicit when-to-use conditions for the risky parameter ('pass activate=true only when you mean spending to start the moment it is created'), states the default paused behavior, and tells the agent the campaign alone never serves so it must be followed by an ad group and ad. Also names the dry-run path via confirm=false.

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 declare this is a non-read-only, non-destructive, non-idempotent write, but the description adds substantial behavior the annotations cannot: the fixed 30-day attribution window, the fact that a setting does not emit events itself, the standard-event-only constraint for campaign goals, and that confirm=false yields a dry run. That is exactly the extra context the annotations leave open.

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-loaded with the core purpose, then organized as a scoped walkthrough of parameters and behavior. Sentences are dense and occasionally run long, but no line is filler given the 0% schema documentation.

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 description supplies the behavioral constraints an agent needs to call this correctly (dry run, attribution window, event semantics). Only the unexplained 'name' and 'account' parameters keep 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?

With 0% schema description coverage the description carries the full parameter burden, and it covers event_type (all enum values listed, custom fallback, name-format constraints), custom_event_name, source_id (format and empty-default behavior), and confirm. It leaves 'name' and 'account' (default empty) unaddressed, a modest gap.

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

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

First sentence states a specific verb and resource ('Creates a ChatGPT Ads conversion event setting') and immediately scopes it with the parenthetical defining what a conversion setting represents. It is clearly distinguishable from chatgpt_ads_conversion_setup and update_chatgpt_ads_campaign, which it references by name.

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 states what to do downstream ('Attach it to campaigns with update_chatgpt_ads_campaign') and where source_id comes from (chatgpt_ads_conversion_setup), plus the constraint that only a STANDARD event can be a campaign goal. It does not give an explicit when-not-to-use or say what to do instead if the pixel source is missing.

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 declare non-read-only, non-idempotent, non-destructive, but say nothing about the dry-run default or eligibility gate. The description supplies both, including that the default confirm=false performs a dry-run — critical behavior an agent must know before invoking.

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?

Extremely dense: the shell-vs-upload distinction is front-loaded, enum values are inline, and the dry-run hint is last. Every clause carries decision-relevant information 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?

For a mutation tool, it covers the dry-run, eligibility prerequisite, and scope boundary; an output schema exists so return values need no explanation. Remaining gaps are the meaning of membership_days and which account customer_id refers to.

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

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

Schema description coverage is 0% across 5 params, so the description must compensate. It documents upload_key_type's allowed values and confirm's dry-run meaning, but leaves name, customer_id, and membership_days (540-day default) unexplained.

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

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

States a specific verb and resource ('creates an EMPTY list shell' for a Customer Match audience), and the word EMPTY plus 'this tool only creates the list' distinguishes it from audience-creation siblings that also populate membership.

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

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

Gives clear context: member upload is a separate step requiring Customer Match eligibility, and confirm=false yields a dry-run. It does not name a specific alternative tool for the upload step or for other audience types, so it falls just short of explicit 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 only declare write/open-world/non-idempotent/not-destructive; the description adds real behavior: the ad is created PAUSED so nothing spends, confirm=false yields a preview, and an existing matching video asset is reused rather than recreated. These are consequential traits an agent cannot infer from the structured fields.

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 purpose before diving into parameter details, and every clause is substantive. Some sentences are long and run-on (the video-format sentence), but there is 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 values need not be described, and the description covers the risky/ambiguous inputs (video formats, asset dedup, required business_name/logo, confirm preview). Minor gaps remain for ad_name and final_url, but the tool is callable correctly from this text.

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 0% schema description coverage across 12 params, the description carries the load well: youtube_video accepted formats (bare id, watch URL, youtu.be, /shorts/), comma-separated headlines/descriptions with char limits (40/90/90), business_name and logo_asset_id requirements with fallback, and the full call_to_action enum. It leaves ad_name, final_url, customer_id, and ad_group_id unexplained, so not a 5.

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 (creates the VIDEO ad inside a Demand Gen ad group) and positions it against the ecosystem ('the last step that makes a Demand Gen campaign able to serve'). An agent can distinguish it from create_demand_gen_campaign and the various create_*_ad siblings without reading 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?

Explains when this tool is the right one ('the only way to run a click-oriented YouTube campaign now that Google moved Video Action campaigns into Demand Gen') and gives a prerequisite path (upload_image_asset if no square logo exists). It does not explicitly say when NOT to use it or contrast directly with create_demand_gen_campaign, so not a full 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 only give the basic safety profile (non-read-only, non-destructive, non-idempotent, closed-world). The description adds critical behavior beyond that: campaign is created PAUSED, confirm=false triggers a dry-run, Google rejects CPC ceilings with OPERATION_NOT_PERMITTED_FOR_CONTEXT, and CTV inventory is on by default. The worldwide-geo incident with '714 clicks in six hours' is exactly the kind of operational hazard an agent needs disclosed.

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