Adbloop Meta Ads

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

The description discloses key behaviors: created PAUSED, WRITES live, and accepts three creative sources. This adds value over annotations (only readOnlyHint false) by specifying state and write impact. However, it does not cover error handling or behavior with conflicting inputs.

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 action and key constraints (paused, write live, creative options). Every sentence adds essential 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?

Despite covering purpose and creative options, the description omits details on most parameters, return values (e.g., ad ID), prerequisites (e.g., adset must exist), and potential errors. For a tool with 11 parameters and no output schema, this is insufficient.

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

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

Schema description coverage is only 27% (3 of 11 parameters described). The description mentions three ways to provide creative but does not explain the other 8 parameters (ad_name, page_id, etc.). It groups 'ad copy fields' vaguely without mapping to schema properties, leaving significant gaps.

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 adds a new ad to an existing ad set, specifies it is created paused, and lists creative options. The verb 'add', resource 'ad to adset', and scope are precise, distinguishing it from bulk operations.

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

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

The description implies usage context (add single ad to existing ad set) but does not explicitly compare to alternatives like bulk creation tools, nor provides when-not guidance. The sibling list contains no direct equivalent, so implicit use is clear but not formally guided.

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?

Even though annotations only provide readOnlyHint=false, the description goes well beyond that by explicitly warning 'WRITES live.' It also discloses behavior such as honoring plan limits, spend guardrails, and capacity, auto-resolving Page/Instagram/pixel assets, and validating inputs. This gives the agent essential operational knowledge 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 tight and front-loaded: the core purpose is in the first sentence, followed by high-priority warnings like 'WRITES live' and guardrail behavior. Every sentence adds useful operational context without fluff or repetition of schema fields. It is an efficient, well-structured description.

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

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

For a complex bulk-write tool with no output schema, the description covers the most critical operational context: live writes, guardrails, auto-resolution, and image requirements. It does not mention confirm-warning behavior or post-creation return values, and it leans on the schema for DPA-specific fields, but the essential calling context is present.

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

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

Schema description coverage is 100%, so the schema already documents every parameter thoroughly. The description adds one useful high-level note (each campaign needs an imageUrl with public or Drive/Dropbox share link), but this mostly restates schema content. The baseline of 3 is appropriate because the description does not significantly deepen 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 begins with a specific verb and resource: 'Create many Meta campaigns at once on ONE account.' It clearly distinguishes itself from siblings like create_campaign and bulk_create_multi_account by emphasizing bulk creation and single-account scope. The 'WRITES live' and rate-limit/guardrail details further pin down its exact nature.

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: this is for bulk-creating many campaigns on one account, and it is a live write operation. It implies alternatives like create_campaign for single campaigns or validate_campaigns for dry-runs, but it never names them explicitly or states when not to use this tool. The 'ONE account' phrasing does hint at the boundary versus bulk_create_multi_account.

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?

Discloses that it writes live (non-readOnly), performs capacity checks, skips throttled accounts (not hammered), and applies currency-aware guardrails. These details add significant value beyond the readOnlyHint=false 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?

Four sentences, each adding value: purpose + limit, behavioral details for each account, specific aspects (guardrails, capacity), and write emphasis. No fluff.

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 core constraints (account limit, throttled skip, guardrails) but lacks details on return value, error handling, confirmation parameter, and chain mechanism. Acceptable given 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?

Schema description coverage is only 33%, and the tool description does not explain parameter syntax or semantics beyond what's in the schema. It mentions the account limit but does not clarify the confirm parameter or campaign structure details.

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

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

The description clearly states it launches the same campaign set across multiple ad accounts, with explicit limits (up to 5 accounts). It distinguishes from siblings like bulk_create_campaigns (single account) and create_campaign (single 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?

Provides clear context: use for launching same campaigns across multiple accounts, with account limit and chain calls for more. Mentions throttled accounts are skipped. Lacks explicit exclusions or alternatives to other tools, but overall usage is clear.

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

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

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 declare readOnlyHint=false, consistent with 'create'. The description adds useful behavioral context: new rules default to alert-only, and it can target campaign, ad set, or ad level. It does not mention permissions, rate limits, or response behavior, but with annotations covering the read-only distinction, the added default and scope details merit a 3.

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

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

The description is two sentences with zero fluff. The main purpose is front-loaded, and the default behavior and scope are stated efficiently. Every sentence earns its place.

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

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

Given the tool has 12 parameters, the description provides the high-level flow, defaults, and supported levels. It does not explicitly mention the interplay of action_value and result_action_type for money actions, but the schema covers that. The description is sufficient for an agent to understand the tool's function and invoke it correctly, with minor gaps that the schema fills.

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

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

Schema coverage is 100%, so the schema already documents all 12 parameters. The description adds semantic linking between metric, threshold, lookback window, and the action types (alert, pause, scale budget), which helps an agent understand the rule logic. It does not explain less obvious parameters like action_value or result_action_type, but those are covered in the schema, so the description meets the baseline for high coverage.

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

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

The description clearly states the verb 'Create' and the resource 'automation rule', then explains the core logic (metric crosses threshold over lookback window, triggers an action). It distinguishes itself from sibling tools like list_automation_rules, delete_automation_rule, and run_automation_rules by focusing on creation and noting the default alert-only behavior.

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 this is for creating rules, while siblings handle listing, deletion, running, and toggling. However, it does not explicitly say 'use this instead of X when...' or mention any exclusions. The context is clear enough for an agent to infer when to use it, but it lacks explicit alternative routing.

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

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

Goes beyond the bare readOnlyHint=false annotation by disclosing that the campaign is created PAUSED for review, that it counts toward a monthly campaign limit, and that the tool WRITES live. Missing niceties such as permission/auth requirements and failure behavior keep it from 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-loaded with scope and state, then routing, then the image requirement and write warning; every clause carries information. The stacked parentheticals make it denser than it needs to be, but there is no filler.

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

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

For a 29-parameter, no-output-schema mutation tool, the description covers routing and the paused/quota behavior well but leaves most of the parameter surface (budget, objective, audience, scheduling) unexplained. Adequate but with clear gaps given the 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?

Schema coverage is only 48% across 29 parameters, so the description must compensate; it does add real meaning for imageUrl (public URL or Drive/Dropbox share link, one image per campaign) but says nothing about budgets, objective selection, CBO, scheduling defaults, or the regulated-category fields the schema only lightly documents. Partial compensation only.

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

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

Specific verb ('Create') plus resource and scope ('ONE Meta campaign'), with the sibling it is not ('use bulk_create_campaigns') named explicitly. An agent can distinguish this from bulk_create_campaigns, bulk_create_multi_account, and add_ad_to_adset without opening any schema.

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

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

Gives clear when-to-use-this (single campaign, free-plan) and when-to-use-the-alternative ('To launch many at once or from a Drive folder, use bulk_create_campaigns (Pro)'), plus the plan/quota context that governs the choice. Nothing about routing is left to inference.

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

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

Annotations only include readOnlyHint: false, so the description carries the full burden of behavioral disclosure. It states the creation action but does not disclose idempotency, permission requirements, duplicate behavior, or what happens on success. The added price format note is useful but already present 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 sentences with no fluff. Purpose is front-loaded; the optionality and price-format clarifications are the most important semantic notes. Every clause earns its place.

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

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

The schema fully documents all 10 parameters and their meanings, which covers the input side. However, as a write operation with no output schema and minimal annotations, the description misses return-value expectations and side-effect behavior. Moderate gap, but parameters are well-covered.

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

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

Schema coverage is 100% and every parameter has a description, so the baseline is 3. The description repeats the 'name required' rule and price format, but adds no new meaning 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 uses a specific verb ('Add') and a clear resource ('a product to a Meta product catalog'), making it unambiguous what the tool does. It also distinguishes itself from sibling tools like update_catalog_product and delete_catalog_product by the action it performs.

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 no guidance on when to use this tool versus alternatives. It does not mention that existing products should be modified via update_catalog_product or warn about duplicate handling. The only guidance is about optional fields, which is parameter-level rather than tool-selection guidance.

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

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

The description adds significant behavioral context beyond the readOnlyHint annotation: campaigns are created PAUSED, respects spend guardrails, is a pro feature, and writes live data. 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?

The description is exceptionally concise: two sentences front-loading the core structure, then additional key details (PAUSED, guardrails, pro feature). 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 tool's complexity (nested schemas) and no output schema, the description covers the primary structure and constraints. It does not explain error behavior or guardrail limits, but overall is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the description does not need to repeat parameter details. The description mentions image/video and DPA, but these are already covered in the schema. No additional semantic depth beyond schema.

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

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

The description clearly states the tool creates ONE campaign with multiple ad sets and multiple ads, specifying supported types (image, video, DPA/catalog). The verb 'Create' and resource 'structured campaign' are explicit, distinguishing it from simpler or bulk 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 implies usage for complex campaign structures (1:N:M) and includes DPA support. It notes the campaign is created PAUSED and honours spend guardrails, but does not explicitly state when to use this tool vs. alternatives like 'create_campaign' or 'bulk_create_campaigns'. Still, context from sibling tools helps differentiation.

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 goes beyond the readOnlyHint=false annotation by explicitly stating the deletion is permanent, signaling irreversibility. It does not detail cascading effects or auth requirements, but the core destructive behavior is clearly disclosed.

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

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

One short, direct sentence with no filler. The key qualifier 'permanently' is included and carries important meaning.

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

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

For a single-parameter destructive action with no output schema, the description provides sufficient context: the action, the target resource, and irreversibility. It stops short of noting any alternative deactivation path, but that is not essential for invoking the tool.

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

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

Schema coverage is 100%, with rule_id already described as 'The rule's id.' The description adds no additional meaning about the parameter, so the baseline of 3 applies.

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

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

States a specific verb ('Delete') and resource ('automation rule') with a clear permanent-action qualifier. This distinguishes it from siblings like set_automation_rule_active 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?

No guidance is given about when to delete versus deactivate or modify an automation rule. The word 'permanently' implies a delete/disable distinction, but no alternative tool or condition is named.

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

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

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?

The annotation readOnlyHint=false already indicates mutation, but the description goes further by stating that removal is permanent. This is a meaningful behavioral disclosure beyond what annotations convey. No other traits (e.g., auth, side effects) are mentioned, but the permanence is a key addition.

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 concise sentences with no filler. The primary verb and resource are front-loaded, and the permanence note adds value without unnecessary length.

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

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

For a simple single-parameter delete operation, the description covers the essential behavior: the action, the target, and the permanence. There is no output schema, but none is needed for a void operation. The description is adequate for an agent to invoke it correctly, though it could optionally mention prerequisites or cascading effects.

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

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

The input schema already fully describes product_id with 100% coverage. The description adds no additional meaning about the parameter, so it relies entirely on the schema. This matches the baseline of 3 for high schema coverage.

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

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

The description clearly states the action (delete) and the target resource (product from Meta catalog), and distinguishes it from sibling create/update/list operations by naming the removal action. The added detail of permanence further clarifies the effect.

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 for deleting a product, but it does not explicitly mention when not to use it or suggest alternatives (e.g., update_catalog_product for modifications). The purpose is unambiguous, but no context or exclusions are provided, so it relies on the agent's 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 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 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?

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?

The annotations already declare readOnlyHint=true, and the description adds that the folder must be public and returns file name and Drive URL. No contradictions. It could add error handling for non-public folders, but overall adds useful 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?

The description is three sentences with no wasted words. The main action is front-loaded, and each sentence adds value: what it does, the constraint, and the typical use case.

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 one parameter and no output schema, the description covers all essential aspects: the public requirement, return format, and integration with another tool. No gaps are apparent.

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% with a basic description. The tool description adds the requirement that the folder must be public, which is not in the schema. This extra context helps the agent understand constraints.

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 specifies a clear verb ('List') and resource ('images/videos inside a PUBLIC Google Drive folder'). It distinguishes from sibling tools by emphasizing its read-only nature and linking to bulk_create_campaigns, which is a separate creation tool.

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

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

The description provides clear context: the folder must be public and shared as 'Anyone with the link', and it's perfect for creating one campaign per image. It implicitly suggests using this before bulk_create_campaigns, but does not explicitly state when not to use or list alternatives.

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

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

Annotations already indicate idempotent, and description adds 'Reversible', which is a key behavioral trait beyond annotations. 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?

Extremely concise: two sentences, no unnecessary words. Front-loaded with action and resource.

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?

Despite simplicity, lacks parameter details and usage context. No explanation of what happens upon pausing or return 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?

With 0% schema description coverage, the description should explain parameters. It only mentions 'by ID' but doesn't clarify 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?

The description clearly states the action ('Pause') and the resource ('campaigns/ad sets/ads'), and distinguishes from sibling tools like 'resume_campaigns' and 'delete_campaigns' by stating reversibility.

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

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

No guidance on when to use this tool vs alternatives (e.g., resume or delete). No context on prerequisites or constraints.

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 indicate write operation (readOnlyHint false) and idempotency (idempotentHint true). The description adds 'Turns spend ON' which confirms the state change, but lacks details on permissions, error handling, or behavior for already-active 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?

The description is very concise (two short sentences) with no extraneous words. However, it could include brief parameter notes without becoming overly long.

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 two parameters and no output schema, the description is incomplete. It omits explanation of meta_account_id, does not specify behavior for multiple IDs, and lacks details on prerequisites or errors.

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 explains campaign_ids as IDs of paused entities but does not mention meta_account_id at all, leaving that parameter's purpose unclear.

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 (resume/activate), the resource (paused campaigns/ad sets/ads), and the effect (turns spend ON). It distinguishes itself from the sibling tool pause_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 use for resuming paused entities but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives beyond what can be inferred 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?

The annotations only provide readOnlyHint: false, so the description carries the burden of behavioral disclosure. It adds that 'Guardrail cap and cooldown still apply' (rate limits) and that it reports what fired (return behavior). These go beyond the annotation and give an agent useful operational context, though it doesn't detail side effects on rule state.

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

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

The description is two sentences with no filler. The primary action and result are front-loaded in the first sentence, and the caveats (guardrail cap, cooldown, testing use) follow efficiently. Every word earns its place.

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

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

For a tool with no parameters and a clear action, the description is nearly complete. It explains what it does, when to use it (testing), and notes operational constraints. The only minor gap is the exact response format, but since there is no output schema, the phrase 'report what fired' gives a general expectation. The tool is simple enough that this is adequate.

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 is empty (0 parameters), so there is nothing to explain. Per the baseline for 0 parameters, a score of 4 is appropriate. The description does not need to add parameter details since none exist, and it doesn't contradict the schema.

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

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

The description clearly states the action: 'Evaluate your active rules right now' and the result: 'report what fired.' It distinguishes from schedule-based execution and is distinct from sibling tools like list_automation_rules (which lists) and create_automation_rule (which creates). The verb 'evaluate' and resource 'active rules' are 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?

The description says 'Useful for testing' which implies the intended use case, but it does not explicitly state when not to use it or mention alternatives. It also says 'instead of waiting for the schedule' which gives context but no exclusions. Lacks direct comparison to sibling tools like set_automation_rule_active or list_automation_rules.

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 readOnlyHint=false, indicating mutation. The description adds valuable context by explaining that off rules 'stay saved but never run', clarifying the side effect of disabling. This goes beyond the annotation without contradicting 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?

A single, front-loaded sentence with no filler. The core action and key consequence (off rules stay saved) are conveyed 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 two-parameter toggle with fully documented parameters and no output schema, the description covers all essential behavior. It tells the agent what the tool does and the consequence of turning a rule off, which is sufficient for correct invocation.

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

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

Schema description coverage is 100% and both parameters are well-described in the schema (rule_id as the id, is_active as true=on/false=off). The description does not add further semantic nuance beyond what the schema already provides, so it meets the baseline but adds no extra value.

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 clear action (turn on/off) and resource (automation rule), immediately distinguishing it from siblings like create_automation_rule, delete_automation_rule, list_automation_rules, and run_automation_rules. The purpose 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?

The description clearly indicates the tool's role in enabling/disabling rules, and the context of sibling tools makes it obvious when to use it (vs. creating, deleting, or running). However, it doesn't explicitly state exclusions or alternatives, so it misses the top bar for explicit 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?

Beyond annotations (readOnlyHint=false), the description adds 'WRITES live' and mentions the guardrail check, giving the agent important behavioral context about live updates and validation. This adds value beyond the structured data.

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

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

The description is concise with three sentences, front-loaded with the main action. Every sentence earns its place without redundancy or filler.

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

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

For a mutation tool with no output schema, the description covers the core behavior, guardrail integration, and parameter specifics. It is complete enough for an agent to understand usage without missing critical context.

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

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

Schema coverage is 100%, but the description adds meaning by specifying that daily_budget is in 'MAJOR units' and that meta_account_id is needed for the guardrail check. This enhances understanding beyond the schema definitions.

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 changes daily budget and/or renames an existing campaign or ad set. The verb 'change' and specific resource distinguish it from siblings like create_campaign or pause_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 explains that the account is required for guardrail checks, providing context for when the tool should be used. However, it does not explicitly state when not to use it or name alternative tools for related tasks.

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

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

The description adds meaningful behavioral context beyond the annotations by specifying partial-update semantics ('omitted fields are left as-is') and clarifying the price representation. It does not cover error cases or response behavior, but for an update operation this is valuable and sufficient.

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 no filler. The core purpose is stated first, followed by the most important operational detail (partial update), then the price format.

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

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

For a 9-parameter update tool without an output schema, the description does not fully capture all context needed. It covers key semantics but omits response behavior, error handling, and direct guidance on when to choose this over create_catalog_product or delete_catalog_product.

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

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

Schema description coverage is only 44%, so the description carries additional burden for parameter meaning. It does clarify price units and the partial-update behavior, but several parameters (url, name, brand, image_url, description) still rely on their names being self-explanatory.

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 ('Edit') and resource ('existing catalog product'), clearly distinguishing it from create_catalog_product and delete_catalog_product. The scope is unambiguous and immediately actionable.

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

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

The phrase 'existing catalog product' provides clear context that this tool is for updates, not creation or deletion. It does not explicitly name sibling tools or exclusion criteria, but the intended use case is evident.

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 value by explaining the per-row verdict types (will_create, will_create_with_changes, will_fail) and the optional guardrail check with meta_account_id. No contradictions.

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?

Description is extremely concise: a single sentence plus a fragment. Every word earns its place, with the purpose front-loaded. No redundancy or wasted text.

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 validation tool with no output schema, the description covers purpose, read-only nature, verdicts, and optional guardrail check. It lacks explicit details on the return format (e.g., list of objects), but the verdict types imply the structure. Annotations provide the destructive hint.

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?

Top-level schema parameters lack descriptions (0% coverage). The description adds meaning for meta_account_id ('to also check spend guardrails') but only refers to campaigns as 'campaign rows' without further detail. The schema's nested item descriptions compensate partially.

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 uses specific verbs: 'Pre-flight check campaign rows BEFORE creating.' It clearly identifies the tool as a validation/dry run, distinguishing it from creation siblings like bulk_create_campaigns. The read-only nature and per-row verdicts are explicitly stated.

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

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

Description advises using this tool 'BEFORE creating', which provides clear context. It also notes that passing meta_account_id adds guardrail checks. However, it lacks explicit exclusions or direct mentions of alternative tools for creation, though the sibling list makes this obvious.

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