Adbloop Meta Ads

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

Description adds context beyond annotations: 'Created PAUSED' and 'WRITES live' clarify the ad's initial state and that the operation is a live write. Annotations only specify readOnlyHint=false, so description provides useful behavioral details.

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 with no superfluous words. Two sentences (plus a fragment) convey all key points 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?

Despite 11 parameters and no output schema, the description omits crucial context: no return value, no prerequisites/permissions, no explanation of 'ad copy fields', and insufficient differentiation from sibling tools. Significant gaps remain for an agent to use the tool effectively.

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 27%, with only creative_id, image_hash, and cta described. Description groups 'ad copy fields' and explains creative options, compensating partially. However, many parameters (ad_name, page_id, headline, etc.) remain unexplained, and the description does not fully bridge the coverage gap.

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

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

Description clearly states 'Add a NEW ad (with creative) to an EXISTING ad set.' It specifies the verb (add), resource (ad), and target (ad set), distinguishing it from sibling tools like create_campaign or 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?

Partially guides usage by stating creative options (creative_id, image_hash, ad copy fields) and that the ad is created PAUSED. Mentions 'supported here (unlike bulk-create)' which hints at alternative but does not explicitly state when to use this tool versus siblings or provide when-not-to conditions.

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 readOnlyHint=false, so description's 'WRITES live' is consistent. It adds context about rate-limit safety and validation, but does not detail failure modes or partial writes. For a write tool, more transparency on side effects would improve this score.

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

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

Three sentences, no wasted words. Front-loaded with action and key constraints. Every sentence serves a purpose.

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 8 parameters and no output schema, the description covers the core purpose and constraints (single account, rate-limit-safe, imageUrl requirement). However, it lacks explanation of return values or side effects, and some parameters remain unexplained, making it moderately complete.

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

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

Schema description coverage is 0%, but the description adds value by explaining imageUrl requirements (public image, Drive/Dropbox share link). However, it does not explain other parameters like confirm, page_id, or meta_account_id. The description adds meaning beyond the schema for a subset of parameters.

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

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

The description clearly states the tool creates many Meta campaigns at once on one account, with specific verb+resource (bulk-create campaigns). It distinguishes from siblings like 'create_campaign' (single) and 'delete_campaigns' by emphasizing bulk creation and live write 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 when to use: for bulk creation on one account with rate-limit safety and validation. It mentions honoring plan limits and auto-using correct page/pixel, which guides usage. However, it does not explicitly state when not to use or name alternatives like 'estimate_bulk_create' or 'validate_campaigns'.

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

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

Adds significant value beyond annotations: discloses live writes (destructive behavior), currency-aware guardrails, capacity check with throttled accounts skipped, and correct Page/Instagram/pixel assignment. No contradictions with readOnlyHint=false.

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

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

Three concise sentences: purpose with constraints, intelligent handling per account, and a warning about live writes. No redundant or vague phrasing.

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 capacity checks, throttling, currency awareness, and correct assets. Missing details on error handling, return value, prerequisites, or the confirm parameter. Overall strong for a creation tool with 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?

Schema coverage is 33% (confirm lacks description). Description adds context for account_ids (up to 5) and chaining, but does not clarify confirm parameter or campaign structure assumptions. Partially compensates for schema 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?

Clearly states the verb (launch), resource (campaign set across multiple ad accounts), and scope (up to 5 accounts). Distinguishes from siblings like bulk_create_campaigns and create_campaign by specifying multi-account replication. Includes constraints like chaining for more accounts.

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

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

Implies usage for replicating a campaign set across multiple accounts. Mentions chaining for >5 accounts. Does not explicitly contrast with sibling tools like estimate_bulk_create or bulk_create_campaigns, but the multi-account focus 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?

Annotations already declare readOnlyHint=true. The description adds value by disclosing the specific output categories (GO/TIGHT/SPLIT/WAIT_OR_SPLIT/WAIT) and fields (utilization, regain minutes), providing behavioral context beyond safety.

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 with only two sentences, each carrying important information. It could be slightly more structured (e.g., listing outputs separately), but it is not verbose and 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?

While the description covers purpose and output, it lacks parameter usage details and does not fully define the output structure (e.g., exact type or format). Given the low schema coverage and no output schema, this is incomplete for a simple tool.

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

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

The schema has 2 parameters with 0% description coverage. The description does not mention any parameter, failing to clarify the meaning or effect of campaign_count or meta_account_id. This 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?

The description clearly states the verb ('Check') and the resource ('ad account's current Meta API rate-limit headroom'), specifies when to use it ('BEFORE a bulk run'), and the unique return values distinguish it from sibling tools like get_guardrails or other 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 explicitly advises using this tool before a bulk run, implying context. It does not explicitly state when not to use it or list alternative tools, but the unique function makes the guidance clear enough.

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 indicate readOnlyHint=false, and description confirms 'WRITES live' and 'created PAUSED for review', adding behavioral context 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?

Very concise, front-loaded with key facts, every sentence serves a clear purpose 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?

Given the complexity (15 parameters, no output schema), the description covers essential behavioral and usage aspects. Slightly lacking on return value details, but adequate for a creation 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 only 13%, yet description adds minimal parameter detail beyond imageUrl requirements. It does not compensate for the low coverage by explaining other parameters.

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

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

Description clearly states 'Create ONE Meta campaign (created PAUSED for review)' with a specific verb and resource. It distinguishes from sibling tools like 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?

Explicitly mentions 'Free-plan friendly — counts toward your monthly campaign limit' and directs to bulk_create_campaigns for bulk operations, providing clear when-to-use and 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?

The description goes beyond annotations (which only have readOnlyHint: false) by explicitly stating 'WRITES live' (consistency), 'Created PAUSED' (initial state), 'Honors spend guardrails' (behavioral constraint), and 'Pro feature' (access requirement). No contradiction with annotations; adds substantial value.

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 with no wasted words. It uses capitalization for emphasis (e.g., 'MULTIPLE', 'PAUSED', 'WRITES') to highlight key aspects. Every piece of information is relevant and 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?

Despite the tool's complexity (nested schema, no output schema), the description covers the core functionality (1:N:M structure, DPA support), behavioral traits (paused, guardrails, pro), and write nature. It could elaborate on error handling or prerequisites, but for the given context, it is largely 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description's mention of 'MULTIPLE ad sets and MULTIPLE ads' aligns with schema but does not add new semantic meaning beyond the existing nested structure. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Create ONE campaign with MULTIPLE ad sets and MULTIPLE ads each', specifying the resource (campaign) and its nested structure. It distinguishes from siblings like create_campaign (single campaign without nested adsets/ads) and bulk_create_campaigns (multiple campaigns). The purpose is specific 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 provides usage context: 'Created PAUSED', 'Honors spend guardrails', 'Pro feature', and 'WRITES live'. It implicitly tells when to use this tool for complex nested structures. However, it does not explicitly exclude simpler campaigns or mention alternatives like create_campaign, leaving some ambiguity for agents.

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 fully discloses the critical behavioral trait: deletion is 'PERMANENT' and 'Irreversible', and requires 'confirm:true'. Annotations already indicate destructiveHint=true, but the description adds essential context about permanence and confirmation requirement, which is valuable 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 extremely concise: two short sentences. Front-loaded with the action ('PERMANENTLY delete') and immediately provides usage guidance. Every sentence is necessary and 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?

For a simple deletion tool with no output schema, the description covers purpose, irreversibility, required confirmation, and provides an alternative. Sibling tools include pause and update, so this context is sufficient for an AI agent to make a correct decision.

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?

Input schema coverage is only 33% (only 'confirm' is described in schema). The description mentions 'confirm:true' but does not explain 'campaign_ids' or 'meta_account_id'. Schema already describes 'confirm' as boolean with 'must be true', so description adds no new semantic value for parameters. Given low coverage, description should compensate but does not.

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

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

The description clearly states the tool's action: 'PERMANENTLY delete campaigns/ad sets/ads by ID'. It specifies the verb 'delete', the resources 'campaigns/ad sets/ads', and the method 'by ID'. This differentiates it from siblings like 'pause_campaigns' which temporarily pauses rather than deletes.

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 tells when to use the tool and when not to: 'Use pause instead if unsure'. It also provides a usage condition: 'requires confirm:true'. This is excellent guidance for an AI agent to choose between permanent deletion and pausing.

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; the description adds 'Read-only' which reinforces but does not disclose additional behavioral traits like dependencies or limitations.

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

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

Two concise sentences with no redundancy; the first states function, the second adds read-only 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 one parameter and no output schema, the description omits what the estimate returns (e.g., time unit), leaving ambiguity for agent usage.

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 maps 'N campaigns' to the required parameter 'count', adding meaning beyond the type-only schema, though it could specify format or range.

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 'Estimate' and resource 'bulk creation time' for N campaigns, clearly distinguishing it from sibling tools like bulk_create_campaigns which actually create.

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 a pre-check before bulk creation (by stating it estimates time) and marks it as read-only, but does not explicitly state when to use or when not to use.

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. The description adds value by specifying the exact output fields (Page name, Instagram username, pixel) and scoping to 'connected to this Adbloop user', providing behavioral context 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?

Two sentences with no wasted words. The first sentence immediately states purpose and output, the second adds a practical 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?

For a parameterless listing tool without an output schema, the description fully explains what it returns and why to use it. No gaps remain 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?

No parameters exist, so the baseline is 4. The description appropriately explains the tool's behavior without needing to cover parameter details.

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

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

The description clearly states the tool lists Meta ad accounts connected to the user, specifies the included fields (Page name, Instagram username, pixel), and distinguishes its purpose from sibling listing tools by focusing on account-level data.

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

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

The description provides a concrete use case ('resolve a spoken account/page name to IDs'), guiding when to use this tool. Though it doesn't explicitly mention when not to use it or compare to alternatives, the context is clear given the sibling tools are for campaigns, ads, etc.

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?

Describes output as a tree structure and notes read-only, consistent with annotations. Lacks detail on pagination or depth, but annotations cover safety.

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 single sentence that front-loads the purpose and structure. No 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?

Simple tool with low complexity. Description is adequate but could be slightly more complete about return format or required permissions.

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. Description only implies campaign_id, leaving meta_account_id unexplained. Does not compensate for missing schema descriptions.

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 it retrieves the full tree of a campaign including ad sets and ads. Distinguishes from sibling tools like list_campaigns which only lists.

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

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

Implies when to use (when full hierarchy is needed) but provides no guidance on alternatives 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. The description adds 'Read-only' but this is redundant. The note about output format compatibility adds some behavioral context, but it's not about the tool's own behavior, rate limits, or auth needs.

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

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

The description is short and front-loaded with the primary purpose. The second sentence adds useful but slightly tangential information, still keeping the description concise.

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

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

The tool has one undocumented parameter and no output schema. The description lacks explanation of output format and parameter semantics, making it incomplete for an agent to confidently invoke 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 description coverage is 0%. The description does not explain the 'limit' parameter at all, leaving the agent without guidance on its meaning or usage.

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 saved creatives with a specific verb and resource. However, it does not differentiate from other list tools like list_ads or list_adsets, which also list resources.

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

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

No guidance on when to use this tool versus alternatives. The note about image_hash and imageUrl is tangential and does not address appropriate 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?

Annotations already declare readOnlyHint=true. The description adds a minor behavioral detail about edit ownership, but does not disclose other relevant aspects like data freshness or permission requirements beyond what annotations imply.

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

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

The description is extremely concise—two short sentences that convey purpose and a key constraint without any fluff. 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?

For a simple read-only tool with one parameter and no output schema, the description covers the essential purpose and a usage constraint. However, it lacks guidance on what the output looks like or how the parameter is used, which would improve completeness.

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

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

Schema coverage is 0%, meaning the parameter 'meta_account_id' lacks any description in the schema. The description does not clarify its purpose, format, or valid values, leaving the agent to infer its usage purely from context.

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

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

The description clearly states the tool's action ('View the spend safety limits') and the resource ('an account'). It is distinct from siblings, as no other tool specifically retrieves guardrails.

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 context that the data is read-only and ownership restriction ('Editable only by the owner'), but does not explicitly specify when to use this tool versus alternatives 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 'Read-only.' Additionally, it adds 'Rate-limit-safe,' which is behavioral context beyond annotations. No mention of authentication requirements or side effects, but the added rate-limit info is valuable.

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 fluff. It is front-loaded with the most important information (rate-limit-safe and metrics list). Could be slightly improved with line breaks, but structure is fine.

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 7 parameters with no explanations, no output schema, and no details on time range usage or filtering, the description is incomplete. For a tool retrieving complex Meta insights, more context is needed (e.g., example usage, required parameters 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?

Schema coverage is 0%, meaning no parameter descriptions in the description. The description only lists the metrics returned (spend, impressions, etc.) and does not explain any of the 7 parameters (level, limit, since, etc.). The schema carries the full burden, but the description adds no parameter semantics.

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 provides performance metrics (spend, impressions, etc.) and labels it as read-only. It is specific about the resource (Meta performance metrics) and includes a verb implied by the name. However, it does not explicitly differentiate from sibling tools like list_campaigns or list_ads, which could be confused for overview-type metrics.

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 mentions 'rate-limit-safe' suggesting safe frequent use, but does not provide context for exclusion (e.g., when not to use) or reference sibling tools that might serve similar purposes.

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 include readOnlyHint=true; the description reinforces this with 'Read-only.' However, it provides no additional behavioral context such as permissions, rate limits, or error handling.

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 one substantive sentence and a parenthetical detail. It is front-loaded and efficient, with no extraneous 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?

As a list tool with no output schema, the description should mention return format, pagination, or record details. It omits these, leaving the agent underinformed 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?

With 0% schema description coverage, the description must explain parameters but does not describe page_id or meta_account_id. It adds no meaning beyond the schema's type and requirements.

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 lead-gen forms specifically for OUTCOME_LEADS campaigns on a Facebook Page, and notes it is read-only. This distinct purpose is not covered by sibling tools.

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

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

The description implies usage when working with OUTCOME_LEADS campaigns, but does not explicitly state when to use it or mention alternatives. No exclusions or when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint=true, and the description adds 'Read-only' and 'Includes creative preview info', providing behavioral context beyond the annotation. 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?

The description is very concise, two short phrases conveying the main purpose and additional detail with no wasted words.

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

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

With no output schema, the description should indicate return fields beyond creative preview. It covers scope but lacks full detail on expected output structure.

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 explain parameters. It only vaguely implies adset_id's role via scope mention, but does not explain limit or meta_account_id. Insufficient.

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' and resource 'ads', and specifies scope (across account or inside one ad set) and extra info (creative preview). This distinguishes it from sibling tools like list_adsets or list_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 scope (account vs ad set) but does not explicitly provide guidance on when to use this tool versus alternatives, nor does it mention 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?

The read-onlyHint annotation already covers the primary behavioral trait. The description adds value by specifying which fields are returned (budget, optimization goal, status) and explicitly stating 'Read-only', reinforcing the annotation. 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?

Two short sentences (14 words) with no wasted words. The key action and resource are front-loaded ('List ad sets'), making it easy to scan.

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 no output schema, the description adequately conveys the purpose and return fields. However, it omits parameter details and usage scenarios, which are needed given the lack of schema descriptions and the presence of many sibling tools.

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

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

With 0% schema description coverage, the description must compensate, but it only implicitly references campaign_id via 'inside one campaign' without naming the parameter or explaining limit and meta_account_id. Minimal additional meaning beyond the parameter names.

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

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

The description clearly states the verb 'list' and resource 'ad sets', with additional context about scope (across account or inside campaign) and what fields are shown (budget, optimization goal, status). This distinguishes it from sibling tools like list_campaigns 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 provides scope options but no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or prerequisites, leaving the agent to infer usage from context alone.

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 'Read-only' tag adds minimal value. The description lists some returned fields but omits pagination behavior, filtering options, or other side effects. With annotations covering core safety, a 3 is appropriate.

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 brief but at the cost of essential details. It is front-loaded with the main verb and resource, but the lack of parameter explanations makes it insufficiently informative. It is concise but not effective.

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 4 parameters with no descriptions and no output schema, the description is grossly incomplete. It fails to explain filtering, pagination, account context, or return structure, leaving the agent with inadequate information to use 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 0%, requiring the description to explain parameters. It does not mention after, limit, status_filter, or meta_account_id at all. Despite 4 parameters, no contextual meaning is provided, severely hindering correct usage.

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 existing campaigns and specifies what information is returned (status, budget, effective status). It distinguishes from sibling creation/deletion tools, 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 does not indicate when to use this tool versus alternatives like get_campaign_structure or list_ads. It only implies read-only, but no explicit guidance on selection among many listing tools.

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

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

Annotations include readOnlyHint: true, and the description adds the public folder constraint and output details. No contradictions; provides useful 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?

Three sentences covering purpose, constraint, output, and use case. No wasted words; front-loaded with actionable information.

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

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

For a simple list tool with one parameter and no output schema, the description adequately explains inputs, constraints, and outputs. Lacks mention of error handling or limits, but sufficient for typical use.

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

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

Schema covers 100% of parameters with description. The description adds the requirement that the folder must be public, going beyond the schema's 'folder link or ID' to specify access level.

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 images/videos from a public Google Drive folder and returns file names and Drive URLs. It includes a specific use case ('create one campaign per image'), differentiating it from sibling tools which focus on campaign 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?

Explicitly states the folder must be shared as 'Anyone with the link' and that it's read-only. Provides a use case but does not explicitly mention when not to use or alternative tools; however, no similar sibling exists.

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 adds 'Reversible' beyond annotations (readOnlyHint=false, idempotentHint=true), indicating the action can be undone. 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 short, front-loaded sentences with no redundancy. Could be slightly expanded for clarity 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?

Minimally complete for a simple pause action, but lacks details on effects (e.g., delivery state), prerequisites, or relationship to sibling tools. No output schema, so return value expectations are missing.

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

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

Schema description coverage is 0%, yet description only says 'by ID' without explaining the parameters 'campaign_ids' and 'meta_account_id'. Fails to compensate for lack of schema descriptions.

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 'Pause' and resource 'campaigns/ad sets/ads' with 'by ID'. Distinguishes from sibling 'resume_campaigns' which is the complementary action.

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 versus alternatives like 'resume_campaigns' or 'delete_campaigns'. Does not specify prerequisites or 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?

The description adds 'Turns spend ON' beyond the annotations, which confirm mutability (readOnlyHint=false) and idempotency (idempotentHint=true). No contradictions, but could mention side effects like cost implications.

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 (one sentence) and front-loaded with the action and scope. However, the brevity sacrifices necessary detail, making it efficient but insufficient.

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 output schema, zero parameter documentation in the description, and the operational complexity (resuming campaigns with potential cost implications), the description is incomplete. It fails to cover return values, success criteria, or prerequisites.

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

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

Schema description coverage is 0%, yet the description provides no information about the parameters 'campaign_ids' or 'meta_account_id'. The agent is left without guidance on what values to pass, which is critical for correct invocation.

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 'Resume (activate)', specifies the resource 'paused campaigns/ad sets/ads', and indicates the action 'Turns spend ON'. It effectively distinguishes the tool from siblings like '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 usage for paused campaigns but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. It minimally guides the agent on 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?

Consistent with readOnlyHint annotation; adds detail on return values (interest names, IDs, audience sizes). No hidden destructive behaviors.

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 covering purpose, output, and utility. No redundant 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?

Covers main purpose and return types, but omits meta_account_id explanation and usage constraints. Adequate but not comprehensive.

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

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

Query parameter is explained via examples, but meta_account_id is not described. With 0% schema coverage, description partially compensates but not fully.

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 searches Meta's targeting interests by keyword, with examples. It distinguishes from sibling tools that focus on campaign 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?

States utility during campaign planning and notes read-only nature, but does not explicitly contrast with alternative tools or provide exclusions.

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

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

While annotations indicate a write operation, the description adds 'WRITES live' and explains the guardrail check behavior (account required, budget checked). This provides context beyond what annotations offer.

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 short sentences, front-loading the primary action. Every sentence contributes meaningful information without redundancy or unnecessary detail.

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

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

The description covers the tool's purpose, the guardrail check, and the write nature. It does not explain return values (no output schema needed) or edge cases like exceeding guardrails, but overall it is sufficiently complete for an AI 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?

The schema has 100% coverage, so baseline is 3. The description adds value by explaining the purpose of meta_account_id (guardrail check) and clarifying that daily_budget is in MAJOR units, slightly enhancing 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 clearly states the verb 'Change' and the specific resources 'daily budget (and/or rename) of an existing campaign or ad set'. It distinguishes from sibling tools like create_campaign and delete_campaigns by focusing on updating existing entities.

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 specifies this tool is for existing campaigns or ad sets, implying it should not be used for creation. It mentions the account requirement for guardrail checks but does not explicitly exclude alternative tools like bulk updates for multiple entities.

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=true; description confirms read-only. Adds behavioral details: per-row verdicts, and with meta_account_id, checks spend guardrails. No contradiction. Provides valuable 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?

Three sentences, front-loaded with the core purpose 'Pre-flight check campaign rows BEFORE creating.' Every sentence adds value; no redundancy or 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?

Given no output schema, the description adequately explains return values (per-row verdicts) and optional behavior (spend guardrails). Sufficient for a validation/dry-run 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?

While schema properties have descriptions (campaigns and meta_account_id), the overall description adds only that meta_account_id enables spend guardrail checks. Schema description coverage is 0% per context, but schema itself has descriptions, so baseline 3 is appropriate.

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

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

The description clearly states it performs a pre-flight check on campaign rows before creation, is read-only, and provides per-row verdicts (will_create, will_create_with_changes, will_fail). This distinguishes it from sibling tools that actually create or estimate 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?

Explicitly says 'BEFORE creating', indicating clear use context. Also notes optional meta_account_id for spend guardrail checks. However, it does not explicitly state when not to use or compare with alternatives like estimate_bulk_create.

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