Adbloop Meta Ads

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the bar is lower, but the description still adds genuinely useful behavior: the ad is created PAUSED (a critical fact for a live-write tool) and 'WRITES live' restates the mutation surface. It does not cover permissions/scopes, whether the creative is auto-published, or error behavior, keeping it short of a 5.

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

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

Four short clauses, all front-loaded: what it does, its resulting state, its input modes, and its write semantics. No filler, and no sentence could be removed without losing a decision-relevant fact.

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 11-param, no-output-schema mutation tool, the description covers the essentials an agent needs to act: target entity, creative sourcing options, and the PAUSED default. What remains unstated is the return value (presumably an ad id) and the conditional parameter requirements for the ad-copy path, which is the main risk of a malformed call.

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 only 27% schema description coverage across 11 parameters, the description carries weight, and it does clarify the ambiguous creative_id vs image_hash vs copy-fields choice. However, it is silent on the conditional dependencies among the remaining params (page_id, website_url, headline, primary_text, cta are all unnecessary for the creative_id path but likely required for the copy path), and meta_account_id is unexplained, leaving a substantial 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 with explicit scoping: a NEW ad with creative into an EXISTING ad set. The caps on NEW/EXISTING/Pausal preempt the most common confusion (creating ads vs. ad sets, or duplicating creatives), so an agent can separate this from list_ads, get_creative_library, or bulk_create_campaigns 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 description clearly frames the three mutually exclusive ways to supply creative content (existing creative_id, library image_hash, or inline ad copy), which is the real decision point when calling this tool. It implies contrast with a bulk path ('this is where saved library creatives CAN be used', 'unlike bulk-create' in the schema) but never names a sibling tool or states when NOT to use this one.

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

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

Annotations only supply readOnlyHint=true; the description adds the substantive behavioral facts the agent most needs: the tool returns a URL for the human to open, no fetching/reading of results happens on the Adbloop side, and it is available on every plan (no gating). Remaining gaps are edge behavior — e.g. what is returned if page_id is invalid or if both query and page_id are supplied.

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 use case, followed by selection modes and the critical no-fetch caveat. Nothing is repeated and no sentence 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 6-param, zero-required, no-output-schema tool the description covers the essentials: what it produces (a link), who consumes it (the user's browser), and that no data comes back. It does not explain how the optional filters interact with page_id mode, which is the one meaningful ambiguity left for an agent composing the call.

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 83%, so the schema already documents query, country, page_id, active_only and exact_phrase. The description adds a mode framing (name/keyword vs exact Page ID) but largely restates what the schema says about page_id, and media_type — the only enum parameter — is undocumented in both schema and description. Baseline 3 fits.

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: builds a link to Meta's public Ad Library for a brand's ads. The framing ('Competitor research', 'The user opens the link in their browser; Adbloop does not fetch or read the results') cleanly separates it from sibling data-returning tools like get_creative_library or get_ad_preview, which an agent might otherwise confuse it with.

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

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

Gives clear context ('Competitor research') and the two selection modes — search by name/keyword vs exact by Facebook Page ID. It also implicitly rules out expecting returned ad data. However, it never names an alternative tool for when the agent actually needs ad creative or insights, so the routing guidance stops short of 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 only declare readOnlyHint=false and destructiveHint=true; the description adds that it WRITES live, that it is rate-limit-safe and pre-validated, and that plan limits, spend guardrails, and account capacity gate execution. That is real context beyond annotations, though it stops short of saying runs can pause for confirmation or what happens on partial failure.

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 short sentences, front-loaded with the core write action and scope before the supporting constraints. Dense and mostly earned, with only mild redundancy against the schema on imageUrl.

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

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

This is a high-complexity bulk mutation with no output schema, and the description never addresses return shape, partial success handling, or batching limits. The confirm/pause semantics that an agent most needs are only discoverable in the confirm parameter description.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including the imageUrl allowlist and geo constraints. The description restates two of them (imageUrl requirement, auto-resolved Page/Instagram/pixel) without adding syntax or format detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

"Create many Meta campaigns at once on ONE account" gives a specific verb, resource, batch semantics, and account scope. The 'ONE account' constraint implicitly separates it from the sibling bulk_create_multi_account, and 'many campaigns' separates it from create_campaign.

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

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

The description implies when the tool applies (batch creation on a single account with guardrails and validation in force) but never names alternatives such as validate_campaigns, estimate_bulk_create, or bulk_create_multi_account, nor does it state when not to use this tool. The agent must infer routing from the sibling list.

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 the annotations: per-account currency-aware guardrails, an automatic capacity check, and the crucial partial-failure rule that throttled accounts are 'skipped, not hammered'. 'WRITES live' reinforces destructiveHint=true rather than contradicting it. What's missing is what a skipped account means for the response/rollback.

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 with the account cap and write warning front-loaded; every clause carries information, and nothing is repeated from structured fields verbatim.

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 nested, destructive bulk-write tool with no output schema, the description leaves gaps: no mention of the confirm flag, no indication of what the per-account result looks like, and no pointer to sibling pre-flight tools. It is adequate to call the tool safely but not to predict its outcome.

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 low (33%) — only account_ids is documented at the top level — so the description carries weight, and it does match the 'up to 5' cap on account_ids. However, it never explains the 'confirm' flag or the top-level 'campaigns' array, leaving a destructive-write gate 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+resource+scope: 'Launch the SAME campaign set across MULTIPLE ad accounts in one call'. The 'MULTIPLE ad accounts' framing distinguishes it from the single-account sibling bulk_create_campaigns without needing to open 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 concrete operational bounds ('up to 5 accounts; chain calls for more') and signals a live write. It does not explicitly say when to prefer estimate_bulk_create or validate_campaigns first, so routing is implied rather than stated.

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

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

Description declares read-only, consistent with readOnlyHint annotation. Also specifies return values (GO/TIGHT/SPLIT/WAIT_OR_SPLIT/WAIT + utilization + regain minutes), adding behavioral detail beyond 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 front-loaded with purpose and return values. No wasted words. Could add parameter details without losing conciseness.

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 no output schema and 0% schema coverage, description provides purpose, usage context, and return format but omits parameter details. Adequate for a simple tool but incomplete regarding inputs.

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 has 0% description coverage, so description must compensate. However, description does not explain the parameters (meta_account_id, campaign_count). campaign_count is left unexplained, which is a significant 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?

Description explicitly states verb (check), resource (ad account's Meta API rate-limit headroom), and context (before a bulk run). Clearly distinguishes from sibling tools by focusing on capacity checking.

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?

States explicit usage context ('BEFORE a bulk run') and read-only nature. No explicit when-not-to-use or alternatives, but context implies appropriate usage.

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 establish readOnlyHint=true, and the description reinforces it ('Read-only') while adding non-annotation context: the 500px threshold rule, accepted link formats, and plan availability. It stops short of describing failure modes for unreachable URLs, keeping it below 5.

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

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

Three tight sentences with no filler, front-loading the action and return value before the input formats and availability caveats. Every sentence carries distinct information.

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

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

With no output schema, the description takes responsibility for describing returns (dimensions plus a width warning) and covers accepted inputs, safety profile, and plan scope. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the single parameter's description already lists 'Public image URL or Drive/Dropbox share link.' The description restates this same format information rather than adding new meaning, so baseline 3 applies.

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

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

States a specific verb+resource ('Check an ad image') and specifies what it returns (width × height, sub-500px warning). No sibling tool overlaps this purpose, so it is clearly distinguishable.

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 frames usage timing ('before using it') and cites the concrete downstream consequence ('Instagram won't deliver those ads'). No sibling alternative is named, but none exists for image validation, so guidance is effectively complete.

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 destructiveHint=true and readOnlyHint=false, so the description only needs to add context. It does: the safe default (alert-only) is disclosed up front, and the pause/scale-budget actions make clear the rule can mutate live delivery. It stops short of warning that pausing halts spend or that budget scaling changes real money at a fixed cadence.

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

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

Three short sentences, front-loaded with the core verb and resource, then the trigger model, then the defaults. Nothing is wasted and the most decision-relevant fact (alert-only default) appears early.

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 mutation tool with no output schema, the description conveys the rule model and the action default clearly. It leaves open what the call returns (e.g. a created rule id) and does not mention that cpa/results rules need result_action_type before taking a money action, though the schema does cover the latter.

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

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

Schema description coverage is 100% and enum values are fully documented, so the schema carries the parameter burden. The description reinforces the lookback window and entity level conceptually but adds no syntax, ranges, or format detail beyond what the schema already says.

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

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

The description uses a specific verb and resource ('Create an automation rule for an ad account') and then explains the rule's conceptual model (metric + threshold + lookback + action), which makes the create-versus-run/delete/list distinction obvious. It never names a sibling explicitly, so it falls just short of a 5.

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

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

'New rules default to alert-only unless you set a different action' gives useful selection context for the action argument, and 'Works at campaign, ad set, or ad level' scopes the tool. But there is no guidance on when to create a rule versus using run_automation_rules or set_automation_rule_active, and no stated 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?

Adds real context beyond the annotations: the campaign is created PAUSED for review, it consumes the plan's monthly campaign quota, and it writes live rather than staging. Quota consumption and the paused-review state are not derivable from readOnlyHint/destructiveHint. It doesn't mention permission requirements or what happens if creation fails partway.

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 short sentences, front-loaded with identity and scope, then prerequisites, then the sibling hand-off, then the mutation warning. Nothing is repeated and nothing is padding.

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

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

For a 35-parameter mutation with no output schema, the description says nothing about what comes back (campaign/ad set/ad IDs) that later calls like pause_campaigns or get_campaign_structure would need. Annotations cover the safety profile and the description covers quota and paused state, but the return-value gap and the thin coverage of 40% of the parameters leave it incomplete for a tool this complex.

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 60% with 35 parameters, so a large minority are undocumented anywhere. The description reinforces the imageUrl/videoUrl requirement and the "one image per campaign" rule, but those are already spelled out in the schema, and the remaining ~40% of parameters get no narrative clarification.

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

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

States a specific verb and resource ("Create ONE Meta campaign") plus the exact composition it produces (one ad set, one ad) and its initial state (PAUSED). The capitalized "ONE" plus the explicit pointer to bulk_create_campaigns makes it distinguishable from the sibling at a glance.

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 bulk work elsewhere ("For many campaigns at once, use bulk_create_campaigns") and states the media prerequisite for image vs video ads. It doesn't cover other plausible alternatives (validate_campaigns, add_ad_to_adset, or what to do when the monthly limit is already exhausted), so it stops short of full when/when-not coverage.

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 and destructiveHint=true, so the write/side-effect profile is known. The description adds nothing behavioral beyond that: no mention of permissions, idempotency or duplicate handling when the same retailer_id is submitted, rate limits, or what a successful add returns. The price-format note restates the schema rather than disclosing behavior.

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

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

Three short, front-loaded sentences with the action first and no filler. The third sentence largely repeats the schema's price description, which is minor redundancy rather than bloat.

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 10 flat parameters fully described in the schema and no output schema, the description covers just enough to call the tool. However, for a catalog write with a destructiveHint, it leaves open what happens on duplicate SKUs, whether a bulk sibling (bulk_create_*) is preferable for many products, and what identifier the response yields.

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

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

Schema description coverage is 100%, so every one of the 10 parameters is already documented, including the price major-units format, currency code, and retailer_id auto-generation. The description's 'only name is required, everything else is optional' and price example duplicate what the schema already states, adding no new semantics. Baseline 3 applies.

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

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

States a specific verb and resource: 'Add a product to a Meta product catalog.' An agent can distinguish it from list_catalog_products and delete_catalog_product, but the description never contrasts it with the very close sibling update_catalog_product, so the create-vs-update boundary is left 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?

Usage is only implied by the verb 'Add'. There is no statement of when to use this instead of update_catalog_product (e.g. for products that may already exist), and no prerequisites or exclusions are given. The note that only 'name' is required is helpful context but is not usage guidance.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true; the description reinforces this with 'WRITES live', making the live mutation unmistakable. It adds context not in the annotations — the Pro plan gate and the minimum source-audience size — but says nothing about reversibility, propagation delay for lookalike builds, or failure modes.

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 short clauses, front-loaded with the action and its constraint; nothing is redundant. The fragments 'Pro.' and 'WRITES live.' are terse to the point of being cryptic, costing a little readability.

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 5-parameter mutation with no output schema and only 40% parameter coverage, the description covers the essentials an agent needs to avoid a failed call (Pro plan, 100-person source, mutation warning). It stops short of explaining what is returned (e.g., new audience id), how long creation takes, or the meaning of meta_account_id.

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

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

Schema coverage is 40%, so the description needs to compensate. It usefully defines ratio ('1 = the closest 1% of the country') and ties source_audience_id to a minimum-size requirement, but leaves meta_account_id, the optional name/default-naming behavior, and valid ratio range largely unaddressed in prose.

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

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

States a specific verb and resource ('Create a lookalike audience') and pins the source to 'one of your custom audiences', which separates it from create_website_audience. It doesn't explicitly name that sibling, but the source constraint is enough for an agent to disambiguate.

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 supplies a real prerequisite (source audience of at least ~100 people) and flags the plan requirement ('Pro'), which helps an agent decide whether the call can succeed. However, there is no explicit when-to-use/when-not guidance and no alternative tool is named for building an audience from a website or pixel instead.

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 destructiveHint annotation, the description discloses important behavior: the campaign is created PAUSED, it writes live, it honors spend guardrails, and it is a Pro feature. These are exactly the safety and operational details an agent needs before invoking a mutating creation 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 compact and front-loaded, stating the core creation shape first and then safety and feature notes. Every phrase carries useful information without redundancy.

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

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

For a complex destructive creation tool with rich schema coverage and annotations, the description covers the essential scope, safety posture, and special DPA/Catalog capability. It is nearly complete, though it could be stronger with explicit sibling routing or return-behavior guidance.

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

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

Schema description coverage is 100%, so the nested campaign, ad set, ad, geo, and DPA fields are already documented in the input schema. The description adds the high-level cardinality model, but it does not add parameter-level meaning beyond what the schema provides.

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

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

The description uses a specific verb and resource: creating a structured campaign hierarchy with one campaign, multiple ad sets, and multiple ads each. It also distinguishes the tool's scope by calling out image/video and DPA/Catalog support, which helps separate it from simpler sibling creation tools.

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

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

The description gives clear context for when this tool applies: one campaign with many ad sets and many ads, including DPA/Catalog dynamic product ads. It does not explicitly name alternatives such as create_campaign or bulk_create_campaigns, so routing still requires inference.

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

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

Annotations already declare write and destructive behavior, so the bar is lower. The description adds useful context beyond annotations: Pro tier requirement, live write behavior, and that audiences cost nothing until used in an ad. However, it does not explain permissions, irreversibility, or return behavior.

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

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

Two short sentences front-load the core action and append operational caveats. 'Pro.' is terse but functional, and the parenthetical about cost is efficient; there is no wasted 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?

The description covers purpose, plan requirement, write behavior, and filters, which is adequate for a simple create operation. But for a 5-parameter tool without an output schema, it omits what is returned (e.g., audience ID) and leaves name/meta_account_id semantics 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?

With 60% schema description coverage, the schema documents pixel_id, url_contains, and retention_days. The description reinforces retention as 'last N days' and the URL-contains filter, and mentions the account pixel. It does not clarify name or meta_account_id, and does not add default or range details beyond the schema.

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

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

The description gives a specific verb ('Create') and resource ('a custom audience of people who visited your website'), and identifies the data source (Meta pixel). It implicitly distinguishes itself from create_lookalike_audience by defining a website-visitor audience, but does not explicitly name or contrast the 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?

There is no explicit when-to-use guidance, no when-not-to-use cases, and no named alternatives. The only contextual hints are 'Pro' and the cost caveat; an agent must infer that create_lookalike_audience is the alternative for lookalike audiences.

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

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

Annotations already declare destructiveHint=true, but the description adds important context: deletion is permanent and requires confirm:true. It also clarifies the non-destructive alternative. It does not describe permissions or downstream effects, but the key behavioral traits are covered.

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

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

Three short sentences, front-loaded with the destructive action, then the confirm requirement, then the safer alternative. Every sentence carries useful information with no waste.

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

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

For a simple two-parameter destructive tool, the description covers the action, irreversibility, mandatory confirmation, and the main alternative. Annotations and schema fill the remaining safety and parameter details, leaving nothing essential missing.

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

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

Schema coverage is 100%, and the schema already documents that confirm must be true and that deletion is permanent. The description reinforces confirm:true but adds no syntax or format detail beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb ('Permanently delete') and resource ('an automation rule'), making the operation unambiguous. It also explicitly distinguishes this tool from set_automation_rule_active by describing that alternative as the non-destructive way to stop a rule.

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 names the alternative tool for stopping a rule without deleting it, which directly tells an agent when not to use this tool. The condition for use is clear: only when permanent deletion is intended.

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?

Aligns with annotations (destructiveHint=true). Adds context: irreversible, requires confirm:true, and permanent nature.

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 convey purpose, irreversibility, and alternative succinctly with no waste.

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?

Covers key deletion behavior but lacks detail on account-level parameters and output, given no output schema and moderate complexity.

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

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

Only mentions confirm parameter and its requirement. With 33% schema coverage, description fails to explain campaign_ids or meta_account_id.

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

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

Description clearly states it permanently deletes campaigns/ad sets/ads by ID, distinguishing it from pause or resume 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?

Explicitly advises using pause instead if unsure, giving clear alternative. Could further specify scenarios for deletion.

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 readOnlyHint=false, so the description's 'Permanently' adds emphasis rather than new information. The confirm-gate mention is useful context beyond the boolean flag, but it largely restates the schema. No detail on irreversibility consequences, cascade effects, or error behavior.

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

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

Two short sentences with zero filler; the destructive nature and the confirmation requirement are both front-loaded. Nothing could be removed without losing signal.

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

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

For a two-parameter destructive tool with annotations declaring its safety profile and no output schema, the description covers the essentials: what is deleted, where, and the confirmation gate. Slightly short on consequences for an irreversible operation, but nothing an agent strictly needs is missing.

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

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

Schema coverage is 100%, and both parameters are documented in the schema itself, so the schema carries the semantic load. The description's mention of confirm:true duplicates the schema text rather than adding format or edge-case meaning. Baseline 3 applies.

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

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

States a specific verb and resource ('permanently delete a product') scoped to 'its Meta catalog', which distinguishes it from update_catalog_product and list_catalog_products without naming them. Clear enough that an agent knows exactly what operation is performed.

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 prerequisite ('Requires confirm:true') is stated, implying the tool will not act without explicit confirmation. However, there is no guidance on when to choose deletion versus update_catalog_product, nor any warning about checking the product exists or is referred to by other objects.

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 destructiveHint=true, but the description adds meaning beyond them: deletion is permanent/irreversible, lookalikes must be removed before their source, a 'Pro' plan appears to be required, and confirm:true is mandatory. These are exactly the behavioral facts an agent needs before firing an irreversible 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?

Three short sentences with zero filler, and the most consequential fact (permanent deletion) plus the ordering constraint are both front-loaded before the low-priority mechanics.

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 3-parameter destructive mutation with no output schema, the description covers permanence, dependency ordering, plan tier, and the confirm gate. It doesn't say what error surface the caller sees (e.g., failure when a source audience still has lookalikes), a minor remaining 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 extra weight, and it does explain 'confirm' as 'Requires confirm:true'. However, audience_id and meta_account_id get no treatment at all; their names are largely self-explanatory, which keeps this at a minimum-viable 3 rather than lower.

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 ('Permanently delete a custom or lookalike audience') and scopes exactly which audience types are affected. The named resource cleanly separates it from sibling deleters like delete_campaigns and delete_catalog_product without ambiguity.

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

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

Gives an explicit ordering prerequisite ('Delete lookalikes before their source audience') and a hard gating requirement ('Requires confirm:true'), which is real directional guidance. It stops short of naming the sibling a caller would use first (e.g., list_custom_audiences) to obtain an audience_id.

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

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

The description adds 'Read-only' which is already covered by the readOnlyHint annotation. It adds the context that this is an estimate, but does not disclose other behaviors like required permissions or what happens with invalid count values. No contradiction with 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 wasted words. Purpose is front-loaded and immediately actionable. Every sentence adds essential 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 simple tool with one parameter and a readOnly annotation, the description is fairly complete: it states purpose, parameter meaning, and safety. However, it does not describe the return format (time estimate), which would be helpful given no output schema.

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

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

The single parameter 'count' has no schema description (0% coverage), but the description adds meaning by stating 'for N campaigns', clarifying that count represents the number of campaigns. This compensates for the schema gap, though bounds or defaults are not specified.

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

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

The description clearly states the tool estimates time for bulk creation of N campaigns. It uses a specific verb ('estimate') and resource ('bulk creation time'), distinguishing it from siblings like 'bulk_create_campaigns' which actually perform the creation.

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 says 'Read-only' implying no side effects, but lacks explicit guidance on when to use this tool versus alternatives like 'bulk_create_campaigns'. It is implied that this is for previewing time before executing bulk create, but no when-not or alternative names are mentioned.

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

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

Annotations already declare readOnlyHint: true, so the description does not need to restate that. The description adds value by specifying the returned fields (Page NAME, Instagram username, pixel), which goes beyond the schema. No contradictions with 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 wasted words. The first sentence states the action and output details; the second gives the use case. Front-loaded and efficient.

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

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

Given no output schema, the description explains the return values (Page NAME, Instagram username, pixel). For a simple list tool, this is adequate. It could mention pagination or filtering, but the tool has no parameters and is likely a straightforward list, so completeness is high.

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 0 parameters and schema coverage is 100% (trivially). The description does not need to explain parameters. It correctly focuses on the output behavior, which is appropriate 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?

The description clearly states the tool lists Meta ad accounts connected to the user, including specific details (Page NAME, Instagram username, pixel). It also provides a concrete use case (resolving spoken account names to IDs), distinguishing it from sibling tools that work with campaigns, adsets, etc.

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 explicitly suggests using the tool to resolve spoken account/page names to IDs, giving clear context. While it doesn't list exclusions or alternative tools, the read-only annotation and sibling list make it sufficiently clear that this is for account listing only.

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

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

Annotations already declare readOnlyHint=true, and the description restates 'Read-only', so that adds nothing. However, 'Pro' discloses a plan/subscription gate that annotations do not cover and that affects whether a call succeeds. Beyond that, no error behavior, rate limits, or the consequence of passing both IDs 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?

Three short sentences, front-loaded with the outcome and immediately followed by the inputs. Every sentence contributes a distinct fact (what it returns, what to pass, safety/tier).

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?

No output schema, but the description states the return is preview links, which covers the response shape adequately for a 4-parameter read tool. The remaining gap is the interaction between ad_id and creative_id in the schema's permissive, neither-required setup.

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 50% schema coverage the description carries real weight: it explains ad_id's origin (create_campaign), offers creative_id as an alternative source, and its list of surfaces maps onto ad_formats. It does not clarify whether ad_id and creative_id are mutually exclusive or whether at least one is required, nor does it explain the format enum values beyond the surfaces named.

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 ('Get preview links') plus concrete resource ('how an ad looks on Facebook Feed, Instagram Feed, Stories and Reels'), and it names the exact return artifact. No sibling tool offers previews, so an agent can distinguish it from list_ads or get_creative_library on purpose alone.

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 tells the agent which identifier to supply ('Give an ad_id (e.g. from create_campaign) or a creative_id'), which is real routing guidance between two input paths. It stops short of stating when-not-to-use it or naming alternatives, but the invocation condition is unambiguous.

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

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

Annotations provide readOnlyHint=true, and the description adds 'Read-only' and clarifies the hierarchical nature of the output (ad sets and ads inside each), which adds value beyond the annotation.

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

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

The description is a single sentence that efficiently communicates the core purpose and behavior with no unnecessary words.

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

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

For a simple read-only tool with two parameters and no output schema, the description covers the essential purpose and behavioral trait. However, it could mention error cases or default behavior.

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

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

The description does not mention any parameters, and schema description coverage is 0%. While it implies campaign_id is needed, it fails to explain the purpose of meta_account_id or provide context for either parameter.

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

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

The description clearly states the tool retrieves the full tree of a campaign including all ad sets and ads. It uses specific verb 'get' and resource 'campaign structure', distinguishing it from siblings like list_campaigns, list_adsets, and list_ads.

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

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

The description implies the tool is for exploring hierarchical campaign structure but does not explicitly state when to use it versus alternatives, nor does it mention any preconditions or limitations.

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

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

The annotation already declares readOnlyHint=true, and the description reiterates 'Read-only' without adding new behavioral details beyond the image_hash/imageUrl note. More context (e.g., pagination, rate limits) would improve transparency.

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

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

The description is concise (two sentences), front-loaded with the purpose, and includes a relevant note. Every sentence adds value with no redundancy.

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

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

Given the simple input schema and no output schema, the description adequately states the purpose and adds a useful note about the output format. However, it lacks details on pagination, ordering, or authentication, leaving some gaps for a complete understanding.

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

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

The input schema has one parameter ('limit') with 0% description coverage, and the tool description does not explain it. The meaning of 'limit' may be inferred, but the description fails to compensate for the lack of schema documentation.

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

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

The description clearly states 'List the user's saved creatives' with a specific verb and resource. The note about image_hash vs imageUrl provides context that differentiates this tool from siblings like add_ad_to_adset and bulk_create_campaigns.

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

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

The description implies usage context by mentioning how the output (image_hash vs imageUrl) relates to other tools, but it does not explicitly state when to use or not use this tool, or provide clear alternatives. The guidance is indirect.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only.' It adds value beyond annotations by noting the 'Pro' requirement and specifying the categories of delivery problems inspected. It stops short of explaining the output shape, but the added behavioral context is meaningful.

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

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

The description is three concise segments: the core purpose with specific examples, the read-only nature, and the Pro requirement. The key action is front-loaded, and every word contributes to the agent's understanding.

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

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

This is a fairly simple one-parameter, read-only tool, so the description is minimally viable. However, it does not explain the single input parameter, nor does it clarify what the returned 'flags' look like since there is no output schema. For a tool without meaningful structured metadata, these omissions matter.

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

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

Schema description coverage is 0%, and the description does not mention meta_account_id at all. The parameter name is self-explanatory, but the description adds no format, optionality, or context beyond the schema. This is a noticeable gap given the lack of schema-level documentation.

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

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

The description clearly states the action ('Flag') and resource ('delivery problems'), then enumerates the exact problem types: disapproved or in-review ads, ads with issues, and ad sets stuck in learning phase. This distinguishes it well from sibling read-only tools like get_insights or get_campaign_structure.

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

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

The description gives useful context ('Read-only. Pro.') and implies the tool is used to check delivery health, but it does not explicitly say when to use it over alternatives or provide any exclusion criteria. The 'Pro' hint is helpful but not a full usage guide.

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

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

The description accurately states read-only behavior, matching the readOnlyHint annotation, and adds that only the owner can edit via settings. This provides additional behavioral context beyond 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 concise sentences front-load the action and include key constraints. No unnecessary words or irrelevant details.

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

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

The description covers the basic action and read-only nature but lacks details on return values or what 'spend safety limits' entails. Given no output schema, this omission reduces completeness for a tool with one parameter.

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

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

The single parameter 'meta_account_id' has no description in the schema (0% coverage), and the description does not explain its purpose or format beyond referencing 'an account'. This leaves meaning unclear for the agent.

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

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

The description clearly states the tool views spend safety limits for an account, using a specific verb and resource. Among siblings focused on campaigns and ads, this tool's purpose is distinct and unambiguous.

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

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

The description mentions it is read-only and editable only by the owner in settings, implying when not to use for editing, but does not explicitly state when to use this tool versus alternatives or provide usage context.

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 readOnlyHint annotation, the description adds a rate-limit safety guarantee, which is a useful operational trait. It also discloses the returned metric set and the day-by-day behavior of time_increment=1. It does not describe return shape or pagination, but for a read-only insights tool this is a minor gap.

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

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

Two short sentences pack the key facts—safety, read-only status, metric scope, and the trend-mode hint—without filler. The most decision-relevant 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?

For a read-only query tool with fully documented optional parameters, the description covers the metric scope and a key invocation pattern. The only notable omission is a comparison with the similarly named get_segment_insights, but the schema and metric list make correct invocation achievable.

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

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

Schema description coverage is 100%, so all 8 parameters are already explained in the input schema. The description's time_increment hint duplicates what the schema already says ('Set to 1 for a day-by-day series') and adds no new parameter-level meaning.

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

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

The description clearly identifies the tool as returning Meta performance metrics and enumerates the specific metrics (spend, impressions, clicks, CTR, leads, purchases, ROAS, frequency), making the purpose concrete. It does not explicitly differentiate from the sibling get_segment_insights, but the metric list makes the general function evident.

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

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

The description gives a concrete invocation hint ('Set time_increment=1 for a day-by-day trend') and signals safety ('Rate-limit-safe', 'Read-only'), but it never states when to prefer this tool over siblings like get_segment_insights or get_delivery_health. Usage context is implied rather than explicit.

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

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

The annotations already declare readOnlyHint=true, and the description redundantly states 'Read-only'. While this adds confirmation, it provides no additional behavioral details such as pagination, error handling, or rate limits. For a read-only tool with annotations, this is adequate but minimal.

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

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

The description is concise (two sentences) and front-loaded with the action. However, it could be structured to include parameter hints or output notes without lengthening much. Still, it is efficient and to the 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?

Given the lack of an output schema and two parameters, the description fails to provide complete context. It does not describe the return format, pagination, or the role of meta_account_id. The tool is simple, but the description leaves key 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, the description should add meaning to the parameters. It mentions 'Facebook Page', which hints at page_id, but does not explain meta_account_id or provide any parameter details. This is insufficient for an agent to understand the parameters beyond their names.

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

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

The description clearly states the verb 'List', the resource 'lead-gen forms', and the scope 'on a Facebook Page (for OUTCOME_LEADS campaigns)'. It distinguishes itself from sibling tools by specifying the campaign type, making the purpose precise and unambiguous.

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it, prerequisites, or contrast with similar tools like list_ads or list_campaigns. The context is implied but not stated.

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

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

Adds real value beyond the readOnlyHint annotation: it discloses the plan requirement ('Pro') and, crucially, that the numeric Opportunity Score itself is not returned — only visible in Ads Manager. That caveat prevents an agent from expecting a score in the response. It does not describe response shape or pagination.

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

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

Three short sentences, front-loaded with the purpose and examples, then the caveat. The fragment 'Pro.' is terse to the point of ambiguity, 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?

There is no output schema, and while the description usefully warns the score is absent from results, it doesn't indicate what the recommendations payload looks like (item fields, actionability). For a simple single-param read tool with annotations covering safety, this is adequate but with clear gaps.

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

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

One parameter (meta_account_id) with 0% schema description coverage, and the description says nothing about it — no ID format, no mention of how to obtain it. Baseline for zero params is 4, but with an undocumented required param the description should compensate and does not.

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 ('Meta's own optimization recommendations for an ad account') and grounds it with three concrete examples (Advantage+ audience, consolidate ad sets, fix budget limits). It clearly is not get_insights or get_delivery_health, though it never names those siblings to make the distinction explicit.

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

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

Implied usage context (account-level optimization opportunities) plus a prerequisite note ('Pro'), but no explicit when-to-use versus get_guardrails or get_delivery_health, and no when-not conditions. The 'Pro' token signals a plan gate but is unexplained abbreviation.

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

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

The description explicitly says 'Read-only', which matches the readOnlyHint annotation and adds no contradiction. It adds the 'Pro' access qualifier, but does not disclose other behavioral traits such as default date ranges, result volume, rate limits, or the Meta breakdown-combination constraint that appears only in the schema.

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

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

Two short sentences plus the 'Read-only. Pro.' fragments are efficient and front-loaded with the main purpose. There is no filler, though the 'Pro.' fragment is slightly ambiguous without additional context.

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

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

Given no output schema and 7 parameters, the description is enough for basic invocation with breakdowns, but it omits important operational details such as date format/defaults, limit behavior, and output shape. The schema carries the Meta-specific breakdown-combination rule, so the description alone would not be fully sufficient.

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

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

The description translates the raw enum breakdown values into understandable segments (placement, device, age, gender, region, hour-of-day), adding practical meaning. Schema description coverage is 57%, and the description does not compensate for undocumented parameters like since, until, or limit, so its added value is modest.

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 and resource ('Break performance down by segment') and enumerates the exact segment dimensions, which clearly distinguishes it from generic insight tools like get_insights. It does not explicitly name a sibling, but the scope is concrete and not a tautology.

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 'to find wasted spend or a fatiguing audience' gives a clear use case and implies when this tool is valuable. However, it does not explicitly say when not to use it or which sibling alternative to choose (e.g., get_insights for raw trends), leaving sibling differentiation 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?

The description states 'Read-only', which matches the annotation readOnlyHint=true, and adds behavioral detail 'Includes creative preview info' beyond the annotation. No 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?

The description is a single sentence that efficiently conveys the core purpose and a key feature (creative preview info). No extraneous content.

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

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

Given 3 unannotated parameters and no output schema, the description is somewhat incomplete. It does not mention response format, pagination, or detailed parameter semantics, but adequately covers the primary use case.

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 explain parameters. It implicitly explains 'adset_id' via 'inside one ad set', but does not explain 'limit' (pagination) or 'meta_account_id' (account identifier). Only 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?

The description clearly states the verb 'List ads' and specifies the scope 'across the account or inside one ad set', distinguishing it from siblings that list other entities (e.g., list_adsets, list_campaigns). It also mentions 'Includes creative preview info', adding specificity.

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

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

The description implies when to use (for ads across account or in one ad set), but does not explicitly state when not to use or name alternatives. The guidance is present but minimal.

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

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

The description adds 'Read-only' beyond the annotation, and lists specific fields shown (budget, optimization goal, status). This aligns with the readOnlyHint annotation and provides useful behavioral context without 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?

The description is two sentences, front-loaded with the action, and contains no extraneous information. Every word adds value.

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

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

Given the absence of an output schema and minimal annotations, the description covers purpose and output contents but misses parameter details. It provides a decent baseline but is incomplete for full agent understanding.

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 compensate. It only implicitly hints at campaign_id via 'inside one campaign' and does not explain 'limit' (pagination) or 'meta_account_id' (account scope). This leaves significant ambiguity for the agent.

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

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

The description clearly states the tool lists ad sets, with the scope 'across the account or inside one campaign.' This distinguishes it from sibling tools like list_campaigns and list_ads, making the purpose unambiguous.

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

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

The description provides context on scope (account-wide vs. per campaign) but does not explicitly guide when not to use it or mention alternatives. For a tool with many siblings, more explicit guidance would improve usability.

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 include readOnlyHint=true, which the description aligns with. The description adds detail about the content of the rules returned but doesn't mention pagination, sorting, or any other behavioral nuances. Given the read-only annotation covers the safety aspect, the description adds moderate value beyond 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?

One concise sentence that front-loads the action and then lists the returned attributes. No wasted words, and the essential information is delivered efficiently.

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

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

For a simple list tool with one optional parameter and no output schema, the description adequately conveys what the tool returns. It could mention pagination or result limits, but given the simplicity and the read-only annotation, it is sufficiently complete.

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

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

The single parameter meta_account_id is fully described in the schema (100% coverage). The description does not add any additional meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states it lists automation rules and specifies the returned fields (condition, action, on/off state, last ran). This distinguishes it from sibling tools like create_automation_rule, delete_automation_rule, and run_automation_rules.

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 the action clearly ('List your automation rules') and the optional filter. While it doesn't explicitly say when not to use it, the sibling names make it evident that this is the read-only listing tool. Could be more explicit about alternatives, but the context is sufficient.

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

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

Annotations already declare readOnlyHint=true. Description adds specific fields returned (status, budget, effective status), providing useful context beyond annotations without 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?

Two short sentences, front-loaded with purpose, no filler. Every word adds value.

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

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

With 4 undocumented parameters and no output schema, the description is too minimal to fully inform usage. Lacks parameter details and return format.

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% and description provides no information about any of the 4 parameters (after, limit, status_filter, meta_account_id). Fails to add meaning beyond the bare 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?

Clearly states verb 'List', resource 'campaigns', and specifies included fields (status, budget, effective status). Distinguishes from sibling tools like create_campaign, delete_campaigns, etc.

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?

Mentions 'Read-only' implying safe usage, but no explicit guidance on when to use this versus sibling listing tools (e.g., list_ads, list_adsets) or when not to use it.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only.' It adds behavioral context beyond annotations by identifying the expected output fields and the prerequisite workflow when catalog_id is unavailable. It does not contradict 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 concise sentences front-load the action and output fields, then provide the prerequisite workflow. Every sentence earns its place with no redundant 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 simple read-only list tool with one required parameter and no output schema, the description covers the action, returned fields, read-only nature, and the fallback for a missing id. It could mention pagination or error behavior, but those are minor gaps given the tool's simplicity.

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

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

The schema already documents catalog_id with 100% coverage. The description adds extra semantics by explaining what to do if the catalog_id is missing: ask the user or find it from their account, which helps the agent understand the parameter's sourcing beyond its type.

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 ('List'), a clear resource ('products in a Meta product catalog'), and enumerates the returned fields (name, price, availability, SKU, brand). It is immediately distinguishable from sibling tools like create_catalog_product or delete_catalog_product.

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

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

The description gives actionable usage context: it requires a catalog_id and tells the agent to ask the user or find the catalog from their account if missing. It does not explicitly exclude alternatives or compare to sibling list tools, but the guidance is sufficient for a single-purpose read-only list.

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

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

Annotations already declare readOnlyHint=true, so 'Read-only' is redundant. The 'Pro' tag does add plan/entitlement context not present in annotations, and the returned fields are disclosed, but pagination behavior and handling of the undocumented limit parameter are not addressed.

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

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

Three short sentences, each carrying distinct information (scope, downstream use, safety/plan) with no filler and the core purpose 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 no output schema, the description usefully enumerates return fields and downstream consumers. For a two-parameter read-only list tool that is nearly sufficient; only limit/pagination semantics are missing.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It implies meta_account_id via 'an ad account's' but says nothing about the limit parameter (default page size, max, or whether pagination applies), leaving half the 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?

States a specific verb and resource ('List an ad account's custom and lookalike audiences') and even names the fields returned (size, type, readiness). It is clearly distinct from siblings like create_lookalike_audience or delete_custom_audience by the list verb, 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?

Gives a concrete workflow cue: the returned ids feed create_campaign's customAudiences / excludedAudiences. That is clear context for when to call it, but there are no exclusions or alternative-tool comparisons.

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

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

Annotations already declare readOnlyHint=true, so the bar is lower; the description nonetheless discloses the access requirement (folder must be shared as ''Anyone with the link'') and what is returned (name plus a Drive URL usable directly as imageUrl). It does not mention pagination, file-count limits, or behavior on empty folders, keeping it short of a 5.

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

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

Four short sentences, all front-loaded with the access constraint and return shape before the workflow hint. No sentence 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 one-parameter read tool with no output schema, everything needed is present: access prerequisite, what is returned, and how the output feeds bulk_create_campaigns. Nothing material is missing.

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

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

Schema coverage is 100% and the single folder_url parameter is documented there with link-or-ID format. The description only reinforces the public-folder constraint, which is meaningful but does not add syntax beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb (list) and resource (images/videos inside a Google Drive folder), and the PUBLIC/''Anyone with the link'' scoping makes it unambiguous. No sibling tool does this, so an agent can select it without opening the schema.

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

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

Explicitly names the downstream workflow (''use it to create one campaign per image in a folder'') and connects to bulk_create_campaigns. The public-sharing prerequisite is stated, but there is no explicit ''when not to use'' or fallback for private folders.

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=true, so the description's 'Reversible' is genuinely additive: it clarifies that pausing is a state change that can be undone, not a deletion. However, it doesn't say whether pausing a campaign cascades to its ad sets/ads, what permissions or account context are required, or what happens to already-paused entities.

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

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

Two short sentences, zero filler, with the core action front-loaded ahead of the reversibility note. Nothing is wasted or buried.

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

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

For a mutation tool with no output schema, 0% schema coverage, and an unexplained second parameter, the definition is thin. It omits cascade behavior for nested entities, error/partial-failure semantics for a batch of IDs, and the role of meta_account_id — all things an agent needs before calling it 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%, so the description must carry the burden and largely fails: 'by ID' hints that campaign_ids takes identifiers but not the format, array limits, or behavior for invalid IDs. The second parameter, meta_account_id, is never mentioned at all, leaving the agent to guess whether it is required in multi-account contexts.

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 (Pause) and resource scope (campaigns/ad sets/ads) plus the lookup key (by ID), so the agent knows exactly what operation it performs. It doesn't name the closest siblings (resume_campaigns, delete_campaigns) explicitly, and there is mild tension between the tool name 'pause_campaigns' and the broader 'ad sets/ads' claim given the parameter is campaign_ids.

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?

'Reversible' implies this is the softer alternative to delete_campaigns, and the sibling set makes resume_campaigns the obvious counterpart, but the description never states when to choose pause over delete or resume. Usage is inferable rather than stated.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuine domain consequence beyond that: 'Turns spend ON' tells the agent this action re-enables real ad spend, which is the key operational risk. It still omits permission requirements and error behavior for invalid or already-active IDs.

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

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

Two short sentences with the action front-loaded and the consequence appended, which is the right shape. The scope inflation ('ad sets/ads') is a defect rather than wasted words, but it does slightly reduce the value of the first sentence.

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

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

For a two-parameter mutation tool with no output schema, the agent still lacks the meaning of meta_account_id, the accepted ID format, and the result of a partial or all-invalid batch. The definition is adequate but leaves real gaps an agent would hit at call time.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it only covers half: 'by ID' tells the agent campaign_ids are identifiers but gives no format or batch expectations. The second parameter, meta_account_id, is never mentioned at all, and 'ad sets/ads' wrongly implies parameters that do not exist in the schema.

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

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

States a specific verb ('Resume (activate)') and resource ('paused campaigns/ad sets/ads by ID'), so an agent can immediately tell this is the opposite of pause_campaigns. It loses a point because it claims ad set and ad support that the schema does not actually accept (only campaign_ids).

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 word 'paused' implicitly defines the precondition for use, and 'by ID' implies the agent must already know identifiers. However, it never names the sibling alternative (pause_campaigns) or states what happens if an entity is already active, leaving selection guidance 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?

It adds real behavior beyond the annotations by disclosing that the guardrail cap and cooldown still apply even on a manual trigger. However, with destructiveHint=true and readOnlyHint=false, the description never says that the rules being evaluated may actually mutate campaigns, budgets or statuses — a caller reading 'evaluate ... and report what fired' could reasonably assume a dry 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?

Three short sentences, each earning its place: what it does, the constraint that still binds, and the intended use case. The most decision-relevant information (manual trigger vs schedule) 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 no parameters and no output schema, the description must carry the return-value burden, and 'report what fired' is the only hint at what comes back. For a destructive, side-effecting execution tool it should also spell out whether actions are actually applied and what a caller should check afterward.

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 imposes no semantic burden and the baseline of 4 applies. The description correctly implies a global run with no scoping options, which is consistent with the empty, additionalProperties=false 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 ('Evaluate your active rules') plus the triggering mode ('right now instead of waiting for the schedule'), which cleanly separates it from list_automation_rules, create_automation_rule and set_automation_rule_active in the sibling set.

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 'instead of waiting for the schedule' clause and 'Useful for testing' give a clear condition for choosing this over the normal scheduled path. It stops short of stating exclusions or naming sibling tools such as list_automation_rules for pure inspection, so it is clear context rather than 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?

The 'Read-only' statement aligns with readOnlyHint=true rather than contradicting it. Beyond the annotation, it discloses the return shape (key, name, type, country), which is meaningful behavioral context since no output schema exists; it stops short of discussing rate limits or pagination.

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

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

Two tight sentences with the purpose and example queries front-loaded, then the downstream consumers and read-only nature. No sentence 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?

With no output schema, describing the returned fields is exactly what the description should do, and it does so. The only gap is that meta_account_id carries no description in either the schema or the text, a minor omission for a 4-parameter lookup 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 75% and the schema already documents query, country_code, and location_types including the default. The description only reinforces this with example query values ('Ahmedabad', 'Gujarat', '380015'), adding little beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Search Meta locations') and narrows the scope to city/state/PIN-code geo targeting with concrete example queries. It also enumerates what is returned (key, name, type, country), so an agent knows exactly what the 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?

Explicitly says the results are meant to feed 'geoLocations' on create_campaign, create_structured, or bulk_create_campaigns, which tells the agent when to reach for this tool. It does not, however, contrast itself with the sibling search_targeting, leaving one plausible alternative unaddressed.

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

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

The description adds value beyond annotations by specifying return fields (names, IDs, audience sizes) and reinforcing read-only nature. It is consistent with the readOnlyHint annotation, providing useful behavioral 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?

Two sentences with no wasted words. The action and purpose are front-loaded. Example keywords and return value summary are efficiently integrated.

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 absence of output schema, the description adequately covers return values (interest names, IDs, audience sizes). It lacks details on pagination or limits, but for a simple search tool this is acceptable. The unexplained 'meta_account_id' parameter is a minor 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 must compensate. It only hints at the 'query' parameter via the keyword example but does not explain 'meta_account_id' or provide syntax/format. This is insufficient for effective parameter understanding.

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

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

The description uses a specific verb ('Search') and resource ('Meta's targeting interests') and provides examples ('yoga', 'small business owners'). It clearly distinguishes from sibling tools which focus on campaign and ad management.

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 states the tool is useful when planning campaigns and gives example keywords, implying its use case. However, it does not explicitly mention when not to use it or compare to specific alternatives, though sibling context makes it clear.

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

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

Annotations already declare that this is a mutation and mark it destructive, but the description adds useful behavioral context: disabling a rule does not delete it, and an off rule stays saved but never runs. It does not cover timing or permission requirements, but it meaningfully supplements 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?

The description is two tight sentences with the main action front-loaded. Every sentence carries useful information.

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

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

For a simple two-parameter toggle with full schema coverage and annotations covering mutation behavior, the description is mostly complete. Minor omissions around effect timing or permissions keep it from being fully comprehensive.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description reinforces that the operation toggles a rule on or off, but it adds no syntax or semantic detail beyond the schema.

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

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

The description states a specific verb and resource: turning an automation rule on or off. This clearly distinguishes the tool from siblings such as run_automation_rules, list_automation_rules, delete_automation_rule, and create_automation_rule.

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

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

The description implies when to use the tool by describing the on/off effect, but it does not explicitly say when to choose it over run_automation_rules or state prerequisites. Usage is clear enough but left mostly implicit.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description adds real value beyond that by explaining the side effect (Meta re-paces the remaining lifetime budget, total cap unchanged) and the 24-hour constraint. It does not spell out what is actually lost/irreversible despite destructiveHint=true, so it is not a 5.

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

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

Front-loads the action in the first clause, then layers budget semantics and the hard constraint, closing with 'WRITES live.' Every sentence carries information. It is dense with parentheticals but not 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?

For a 3-param, all-required mutation with full schema coverage and no output schema, the description covers action, side effects, and a key validation rule. Missing only permissions/account-level prerequisites and any statement of failure behavior, which keeps it from a 5.

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

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

Schema coverage is 100%, so baseline is 3; the description earns above that by adding a constraint on end_time that the schema lacks — with a lifetime budget the new end must be more than 24 hours after the ad set's start. It still says nothing extra about adset_id or meta_account_id, which the schema handles.

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+scope: 'Change the END time of an existing ad set' — deliberately narrow, updating only the end time, not budget or status. That scope cleanly separates it from siblings like update_campaign_budget and pause_campaigns 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?

Gives a concrete motivating scenario ('start a fixed run once delivery is confirmed') and states a hard precondition for lifetime-budget ad sets (end must be >24h after start). It does not state when NOT to use this tool or point to an alternative, 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?

Adds context beyond the annotations: the budget is validated against spend guardrails tied to the account, which is genuine operational information an agent cannot see elsewhere. 'WRITES live' largely restates readOnlyHint=false and destructiveHint=true, and the description does not say what happens on guardrail failure or whether the change triggers re-review.

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

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

Three short sentences front-loaded with the action and scope, then the prerequisite and the write warning. No sentence is padding.

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

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

For a destructive write with no output schema, it covers the action, the required account, the guardrail validation, and that it writes live. It stops short of describing side effects such as learning-phase reset, review, or the failure mode when a budget exceeds guardrails.

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

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

Schema coverage is 100%, so entity_id (campaign CBO vs ad set), daily_budget in major units, and the required meta_account_id are already fully documented. The description adds only the rationale for the account parameter, not new semantics, so baseline 3 applies.

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

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

States a specific verb and resource: changing the daily budget and/or renaming an existing campaign or ad set. This is clearly distinguishable from siblings like pause_campaigns, update_adset_schedule, or delete_campaigns without needing 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?

Implies usage ('existing campaign or ad set') and gives one prerequisite (account required for guardrail check), but offers no when-not guidance, no mention of alternatives such as create_campaign or get_guardrails, and no exclusions for entities of other types.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description usefully qualifies that behavior by declaring partial-update semantics where omitted fields are preserved, which is exactly the kind of nuance annotations cannot express. It still omits auth requirements, error behavior, and whether the response returns the updated record.

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

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

Three short sentences, front-loaded with the action and then the two rules that actually change how the call is built. No filler and no repetition of the tool name.

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

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

For a 9-parameter mutation tool with no output schema, the description covers the two things an agent could plausibly get wrong: full-object overwrite risk and price/currency formatting. A note on what is returned or on failure modes for an invalid product_id would close the remaining 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 coverage is only 44%, so the description should compensate more than it does. It adds real meaning for price (major units as a string, with an example) and reinforces that currency belongs with price, but url, name, brand, image_url, and description remain undocumented beyond self-evident names.

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

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

States a specific verb and resource ("Edit an existing catalog product"), which cleanly separates it from create_catalog_product, delete_catalog_product, and the campaign/adset siblings. It does not explicitly route to list_catalog_products for reads, but the operation is unambiguous.

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

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

"Send only the fields you want to change; omitted fields are left as-is" is a concrete invocation rule that tells the agent to send a sparse patch rather than a full object. No explicit when-not or named-alternative guidance is given, which keeps it out of 5 territory.

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?

readOnlyHint=true already covers the safety profile, so the 'Read-only' sentence is redundant. The description does add real behavioral context: the three per-row verdict outcomes and the fact that meta_account_id extends the check to spend guardrails. It omits what happens on malformed rows or how expensive the check is.

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?

Telegraphic and front-loaded: purpose, safety, output categories, optional parameter, in that order. The single 'Read-only' sentence duplicates the readOnlyHint annotation and earns little.

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

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

For a two-parameter dry-run tool with no output schema, the description supplies the essential return semantics (verdict categories) and the guardrail-check flag. Missing only edge-case behavior, such as how invalid rows are reported or whether all rows are evaluated before returning.

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?

No output schema exists and top-level parameters carry no schema descriptions, so the description must compensate. It does explain meta_account_id's effect (guardrail checks), which the schema leaves blank, but says nothing about the campaigns array beyond 'campaign rows' at the top level, relying entirely on the richly described nested properties.

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 (pre-flight check) and resource (campaign rows) plus the timing constraint 'BEFORE creating', which implicitly separates it from create_campaign and bulk_create_campaigns. It never names a sibling explicitly, so an agent must infer the routing itself.

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 use ('BEFORE creating') and a conditional enhancement ('Pass meta_account_id to also check spend guardrails'). It stops short of naming alternatives such as create_campaign or bulk_create_campaigns or stating when validation is unnecessary.

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